Так…
Я немного читал о REST , и идея позади этого звучит неплохо, но вопрос в том, может ли она легко интегрироваться в стандартный поток веб-страницы?
Например, пользователь создает какой-то элемент, сообщение в блоге или что у вас есть, и теперь он хочет его удалить, поэтому он нажимает ссылку «удалить» на странице. Что теперь? Как мы выдаем запрос DELETE, например, http://mysite.com/posts/5
? И как мы обрабатываем этот запрос? У меня нет опыта работы с cURL или что-то в этом curl_init('http://mysite.com/posts/5')
, но из-за его внешнего вида мне пришлось бы curl_init('http://mysite.com/posts/5')
а затем немного поработать. Но где бы я даже поставил этот сценарий? Это должно быть на другой странице, которая нарушит всю идею REST. Тогда я просто хотел бы получить другую страницу, которая, в свою очередь, DELETE
страницу, которую я изначально предназначил?
Именно поэтому люди редко используют REST
или есть хороший способ сделать это?
Похоже, мне нужно уточнить. Люди предлагают включить в URL такие слова, как «DELETE» и «POST». Я считаю, что REST диктует, что у нас есть уникальный URL для каждого ресурса, но не для каждого действия на этом ресурсе. Я предполагаю, что это также означает, что у нас есть только один и только один URL для каждого ресурса. т.е. я хочу, чтобы уметь удалять или просматривать содержимое определенной записи с одного URL (путем отправки либо DELETE, PUT, POST, либо GET), а не разных URL-адресов с дополнительными параметрами
С спокойным сервером один и тот же url (say / books / 1) может отвечать на множество разных глаголов. Эти глаголы, GET, POST, PUT и DELETE вместе с этим путем указывают, что вы хотите сделать с данными на сервере . Ответ ответит на ваш запрос.
REST – это доступ к данным предсказуемым и разумным способом.
Если вы исходите из сильного фона PHP, где каждый URL-адрес должен сопоставляться определенному файлу, вы правы, это не имеет смысла. Две наиболее заметные среды разработки RESTful, ASP.NET MVC и Rails, имеют специальные серверы (или логику сервера), которые читают глаголы и делают для вас специальную маршрутизацию. Это то, что позволяет «нормальному потоку» приложения проходить, как и следовало ожидать. Для PHP существуют рамки, которые помогают в этом, например WSF2 WSF .
Возьмем, к примеру, ваш пример. У нас есть сообщения, и мы хотим их удалить.
Начнем с посещения url like / posts / 4. Как и следовало ожидать, это показывает пост 4, его атрибуты и некоторые действия, которые вы могли бы предпринять. Запрос на предоставление этого URL-адреса будет выглядеть как GET /posts/4
. Ответ содержит HTML, который описывает элемент.
Пользователь нажимает ссылку «Удалить элемент 4», часть HTML. Это отправляет запрос, например DELETE /posts/4
на сервер. Обратите внимание, что это повторно использовало URL /posts/4
, но логика должна быть другой.
Из HTML-форм и веб-браузеров многие из них по умолчанию изменят ссылку с методом = «удалить» на ссылку method = «post». Вам нужно будет использовать Javascript (что-то вроде этого ), чтобы изменить глагол. Ruby on Rails использует скрытое поле ввода ( _method
), чтобы указать, какой метод следует использовать в форме, в качестве альтернативы.
На стороне сервера выполняется логика «удалить элемент». Он знает, что нужно выполнить это из-за глагола в запросе ( DELETE
), который соответствует выполняемому действию. Это ключевой момент REST, что HTTP-глаголы становятся значимыми.
После удаления элемента вы можете ответить на страницу, например «yep, done», или «no, sorry, вы не можете этого сделать», но для браузера имеет смысл поставить вас куда-то еще. Элемент, удаляемый, отвечающий перенаправлением на GET /posts
имеет смысл.
Если вы посмотрите на журнал сервера, будет очень понятно, что все сделали с сервером, но это не так важно, как …
Еще одним ключевым моментом REST является то, что он хорошо работает с несколькими форматами данных. Предположим, вы пишете программу, которая хотела бы читать и взаимодействовать с блогом программно. Вам могут потребоваться все сообщения, указанные в XML, вместо того, чтобы очищать HTML для получения информации.
GET /posts/4.xml
интуитивно понятен: «Сервер, пожалуйста, дайте мне xml, описывающий сообщение № 4». Ответ будет таким, что xml. Сервер RESTful делает очевидным, как получить нужную информацию.
Когда вы сделали запрос DELETE /posts/4.xml
, вы спрашиваете: «Сервер, пожалуйста, удалите элемент №4». Ответ вроде «Хорошо, конечно», как правило, достаточно, чтобы выразить, что произошло. Затем программа может решить, что еще она хочет, и сделать другой запрос.
Ну одним из способов является вызов AJAX с использованием метода DELETE.
Сервер REST от Facebook – это псевдо, вы можете сделать это как они, запрашивая метод post: POST, GET и т. Д. Действие и другие значения, которые вам нужны для этого запроса.
Почему я говорю, что facebook – это псевдо-REST-сервер? : хорошо, одна из Принципов REST говорит:
- Каждый ресурс уникально адресуется с использованием универсального синтаксиса для использования в гипермедиях
в facebook у вас есть только /server.php, и там вы делаете запрос, даже для (POST, GET, PUT, DELETE …)
другой способ использует mod_rewrite и анализирует URL-адрес, который клиент запрашивает
EDIT: просто нашел это , выглядит интересно. Повеселись!
Я не думаю, что REST редко используется. Вы используете его прямо сейчас, в StackOverflow. Что касается вашего конкретного примера, вы можете отправить DELETE-запросы, хотя XMLHttpRequest в браузерах, которые его поддерживают. Когда JS выключен или для несовместимых браузеров вы можете сделать что-то вроде:
POST http://foo.com/delete?post=5
Не идеальный, но еще более спокойный, чем многие сайты.
EDIT: изменено на POST
В зависимости от того, какую структуру вы используете, существуют модели, которые определяют, как обрабатываются действия для каждого ресурса.
В основном, используя другой параметр, вы хотите отправить ресурс, какое действие нужно выполнить. Этот параметр может быть отправлен, например, через AJAX / JS.
Если вы хотите сделать это без javascript / ajax (в случае его отказа), тогда будет работать и метод POST формы, посылая ресурсу дополнительный параметр ACTION.
Конечно, в обоих случаях вы должны учитывать безопасность и следить за тем, чтобы они не отправляли ресурс в действие, которого им не должно быть. Обязательно выполните проверку на сервере и отправьте соответствующий ответ или сообщение об ошибке.
Сценарии на стороне клиента, будь то через JS / Ajax или форму POST или другие методы, требуют дополнительной меры предосторожности.
Отредактировано после разъяснения с плаката.
Не переусердствуйте. Вы не сможете это сделать с помощью прямых HTML-форм и браузера. Они не поддерживают метод DELETE . Ajax может это сделать.
Я хочу УДАЛИТЬ, чтобы ПРОСМОТРЕТЬ содержимое определенной записи с одного URL (путем отправки DELETE, PUT, POST или GET), а не разных URL-адресов с дополнительными параметрами
Удалить для просмотра? Я не уверен, что понимаю, но ваше удаление должно быть сделано через заголовки, а не через URL. Метод delete не должен возвращать представление. REST – это услуга , а не все запросы предназначены для визуального потребления.
Если у вас действительно нет выбора об использовании глагола DELETE, я бы предложил следующее:
POST http://mysite.com/Trashcan?resourceUrl=/Customer/75
Какой url вы используете, на самом деле не имеет значения для REST, однако, легче понять способ REST взаимодействия, если ваши URL-адреса полностью исключают глаголы.
Я видел так много вопросов как от Rails, так и от пользователей ASP.NET MVC, которым нужно выйти за рамки стандартных «действий», и поэтому возникает соблазн просто добавить новое действие на контроллер. Проблема с этим заключается в том, что вы просто выбросили унифицированное ограничение интерфейса REST.
Метафора метафора не является единственным способом удаления удалений, но я бы сказал, что это так же ясно, как читать «удалить» в URL-адресе.
Вот еще несколько «существительных» способов замены глаголов.
POST http://mysite.com/Printer/75/PrintQueue?url=http://mysite.com/Document/xyz POST http://mysite.com/CurrentLogins?user=bob POST http://mysite.com/QueryProcessor?query=FindMyInformation POST http://mysite.com/SearchEngine?searchTerms=cat,blue,furry POST http://mysite.com/OrderProcessor?cart=http://mysite.com/user/2323/cart
Иногда вам нужно немного подумать о том, чтобы придумать язык, основанный на существительном, и может показаться педантичным, чтобы попытаться сделать это, но для меня преимущество исходит из способности управлять моими переменными. Я собираюсь иметь переменное количество ресурсов в моем интерфейсе, независимо от того, что я делаю, если я могу исправить количество глаголов, которые могут работать на этих ресурсах, тогда я уменьшу одну из моих переменных.
Другой способ сделать это, предполагая, что запрос на основе webbased / webapplication будет иметь 2 кнопки submitbuttons. Поскольку PUT и DELETE используют один и тот же uri / url. Вы можете добавить определенную форму удаления и прикрепить к этой кнопке удаления определенное имя, поэтому, когда это отправляется через сообщение, вы можете использовать это имя-кнопку, чтобы превратить действие в DELETE