Какие самые лучшие / распространенные глаголы и действия для URL-адресов RESTful?

86

Я пытаюсь найти информацию о лучших и наиболее распространенных действиях URL RESTful.

например, какой URL-адрес вы используете для отображения сведений об элементе, для редактирования элемента, обновления и т. д.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

хм. спасибо всем, кто помогал :)

rest 
— Pure.Krome
источник

Ответы:

173

Используйте URL-адреса для указания своих объектов, а не действий:

Обратите внимание, что вы впервые упомянули не RESTful:

/questions/show/<whatever>

Вместо этого вы должны использовать свои URL-адреса для указания своих объектов:

/questions/<question>

Затем вы выполняете одну из следующих операций с этим ресурсом.

ПОЛУЧИТЬ:

Используется для получения ресурса, запроса списка ресурсов, а также для запроса информации о ресурсе только для чтения.

Чтобы получить ресурс с вопросами:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Чтобы перечислить все ресурсы для вопросов:

GET /questions HTTP/1.1
Host: whateverblahblah.com

ПОЧТА:

Используется для создания ресурса.

Обратите внимание, что следующее является ошибкой:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Если URL-адрес еще не создан, вы не должны использовать POST для его создания при указании имени. Это должно привести к ошибке "ресурс не найден", потому что он еще не существует. Вы должны сначала РАЗМЕСТИТЬ ресурс на сервере. Вы можете возразить, что, создавая новый вопрос, вы также обновляете ресурс / questions, поскольку теперь он будет возвращать еще один вопрос в своем списке вопросов.

Вы должны сделать что-то вроде этого, чтобы создать ресурс с помощью POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Обратите внимание, что в этом случае имя ресурса не указывается, вам будет возвращен URL-путь нового объекта.

УДАЛЯТЬ:

Используется для удаления ресурса.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

СТАВИТЬ:

Используется для создания ресурса или его перезаписи при указании URL-адреса ресурсов.

Для нового ресурса:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Чтобы перезаписать существующий ресурс:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Да они такие же. PUT часто описывается как метод «редактирования», поскольку, заменяя весь ресурс слегка измененной версией, вы редактируете то, что клиенты будут ПОЛУЧАТЬ, когда они сделают это в следующий раз.

Использование REST в HTML-формах:

Спецификация HTML5 определяет GET и POST для элемента формы .

Атрибут содержимого метода - это перечисляемый атрибут со следующими ключевыми словами и состояниями:

  • Ключевое слово GET, сопоставление с состоянием GET, указывающее метод HTTP GET.
  • Ключевое слово POST, сопоставление с состоянием POST, указывающее метод HTTP POST.

Технически спецификация HTTP не ограничивает вас только этими методами. Технически вы можете добавлять любые методы, которые захотите, однако на практике это не очень хорошая идея. Идея состоит в том, что все знают, что вы используете GET для чтения данных, поэтому это запутает ситуацию, если вы решите вместо этого использовать READ. Тем не менее ...

ПАТЧ:

Это метод, который был определен в формальном RFC. Он предназначен для использования, когда вы хотите отправить только частичную модификацию ресурса, он будет использоваться так же, как PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Разница в том, что PUT должен отправлять весь ресурс, независимо от того, насколько он велик по сравнению с тем, что на самом деле было изменено, в то время как PATCH вы можете отправлять только изменения.

— Брайан Р. Бонди
источник
Привет, Брайан ... чем больше я это читаю, тем больше в нем смысла. Я предполагаю, что некоторые браузеры (или версии браузеров) не поддерживают PUT или DELETE? если это так, используем ли мы вместо этого POST?
— Pure.Krome 02
1
Привет, Pure.Knome; Веб-браузеры поддерживают их все, а также любая HTTP-библиотека должна поддерживать их все.
— Брайан Р. Бонди
4
Кстати, я бы порекомендовал купить эту книгу, если вы хотите узнать все о REST oreilly.com/catalog/9780596529260
— Брайан Р. Бонди
1
@Brian: еще несколько вопросов о ваших примерах PUT. >> PUT / questions / <new_question> Зачем вам это делать вместо >> PUT / questions /, потому что все данные в форме будут использоваться для создания нового ресурса? (продолжение следующего комментария) ...
— Pure.Krome 03
1
@ Брайан Р. Бонди, спасибо за отличный ответ. POST-запрос к существующему ресурсу описывается как «добавление» в книге oreilly's restful book (pg: 100,101), в отличие от вашего общего термина «изменение». В конце концов, добавление более специфично, чем изменение - что может передавать «PUT в существующий ресурс» - и семантически звучит более корректно для POST - добавление нового ресурса к указанной ссылке, либо добавлением, либо созданием дочернего ресурса для этого .
— Озгюр
11

Если предположить, /questions/10что это правильный вопрос, то для взаимодействия с ним используется метод.

POST, чтобы добавить к нему

PUT, чтобы создать или заменить его

GET для просмотра / запроса

и DELETE, чтобы хорошо .. удалить его.

URL не меняется.

— Аллен Лалонд
источник
4
Неправильно. PUT должен быть идемпотентным. Вы должны иметь возможность выполнять один и тот же запрос PUT много раз, но с первого раза это не даст результата. Таким образом, создание ресурса с каждым запросом PUT не идемпотентно.
— aehlke
3
«Методы PUT и DELETE определены как идемпотентные, что означает, что несколько идентичных запросов должны иметь тот же эффект, что и один запрос.», Использование put в URI, который в настоящее время не делает ресурс доступным, может создать ресурс. Немедленное повторное ПОМЕЩЕНИЕ просто сделало бы это снова, что не имело бы никакого эффекта. Таким образом вы создаете ресурс, но запрос все еще идемпотентный. Если вы позже вернетесь и захотите изменить ресурс, вы можете PUT использовать тот же URI с другими данными (это будет другой запрос, который сам может быть повторен любое количество раз с тем же результатом).
— Allain Lalonde
1
На самом деле, взгляните на ответ, который получил 25 голосов выше, в котором говорится, что PUT можно использовать для создания или замены ресурса.
— Allain Lalonde
3
Создание работает только до тех пор, пока разрешено указание ID нового ресурса. Хотя это возможно, пользователю
— гораздо удобнее отправлять
2
@aehIke Создание нового ресурса с помощью PUT не делает его неидемпотентным, поскольку идея состоит в том, что если я 'PUT / items / 10' и элемент 10 не существовал ранее, он будет просто создан. Однако, если я снова «PUT / items / 10» во второй раз, то теперь он уже существует, поэтому он будет просто заменен, поэтому идемпотентность сохраняется, поскольку последующие запросы PUT не имеют нового побочного эффекта. (Конечно, это при условии, что я продолжаю ставить один и тот же предмет каждый раз)
— Алаппин
3

Я собираюсь рискнуть и предположить, что вы имеете в виду стандартные контроллеры для MVC, когда говорите URL-адреса "RESTful", поскольку ваши примеры могут считаться не-RESTful (см. Эту статью).

Поскольку Rails действительно популяризировал стиль URL-адресов, который, кажется, вас интересует, я предлагаю ниже действия контроллера по умолчанию, производимые ScaffoldingGenerator в Ruby on Rails. Они должны быть знакомы любому, кто использует приложение Rails.

Введенные в шаблоны действия и представления: index, list, show, new, create, edit, update, destroy

Обычно вы строите это как:

http://application.com/controller/<action>/<id>
— tvanfosson
источник
5
Соглашения о внеполосных URI НЕ являются RESTful. Цитата самого Филдинга: «REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управления своим собственным пространством имен. Вместо этого разрешите серверам инструктировать клиентов о том, как создавать соответствующие URI , как это делается в формах HTML и шаблонах URI, путем определения этих инструкций в типах мультимедиа и связях .. »
— aehlke
1

Вот отображение ваших текущих URL-адресов с использованием принципа REST:

/question/show/<whatever>

Если вы определяете вопрос как ресурс, он должен иметь уникальный URL. Использование GET для его отображения (получения) - обычная практика. Это становится:

GET /question/<whatever>

/question/edit/<whatever>

Теперь вы хотите, чтобы у вашего пользователя было другое представление того же ресурса, которое позволяет ему редактировать ресурс (возможно, с элементами управления формой).

Здесь есть два варианта: ваше приложение - это приложение (а не веб-сайт), тогда вам может быть лучше использовать JavaScript для преобразования ресурса в редактируемый ресурс на стороне клиента.

Если это веб-сайт, то вы можете использовать тот же URL-адрес с дополнительной информацией, чтобы указать другое представление, обычная практика выглядит так:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Это сделано для того, чтобы изменить вопрос, поэтому PUT - правильный метод:

PUT /question/<whatever>

/question/list   (lists the questions)

Список вопросов на самом деле является родительским ресурсом вопроса, поэтому, естественно, он:

GET /question

Теперь вам может понадобиться еще:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Тада :)

— Винсент Роберт
источник
-1

Ваши четыре примера могут быть такими:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Чтобы добавить вопрос:

POST /questions q=What+is+the+meaning+of+life

Сервер ответит:

200 OK (or 201 Created)
Location: /questions/456
— Pbreitenbach
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.