Оставшиеся URL-адреса с данными в строке запроса или телом запроса?

Какое правило для передачи данных в URL REST в строке запроса по сравнению с телом запроса?

Т.е.: вы создаете сервис для добавления хоккеистов. Вы можете пойти с:

PUT /players 
{ "name": Gretzky }

или

PUT /players?name=Gretzky

Если вы передаете большое количество данных, вам нужно перейти с параметром # 1, так как существует ограничение на длину URL. Но кроме этого, почему бы просто не использовать строку запроса для передачи данных?

Обновить. Удалено комментарий, в котором вы можете проверить опцию # 2 в браузере. Реализовано (duh), что вы можете использовать GET-ы в своем браузере.

Ответ 1

Основываясь на определении HTTP PUT, ваш первый запрос переписывает список игроков с новым списком, который содержит только одно имя игрока. Это не добавление к списку игроков.

Второй вариант для меня не имеет большого смысла. Выполнение PUT без тела несовместимо со значением PUT.

Учитывая, что одно из стандартных определений POST заключается в добавлении к существующему ресурсу, я не уверен, почему вы не сделали

POST /players 
{ "name": Gretzky }

Если вы уверены, что все имена игроков будут уникальными, вы можете использовать PUT следующим образом:

PUT /player/Gretzky
{ "name": Gretzky }

Когда вы решили сделать REST на HTTP, вы соглашаетесь использовать HTTP так, как это определено в RFC2616. Это означает, что означает ограничение по равномерному интерфейсу. И только для того, чтобы быть педантичным, нет такого понятия, как URL REST, и вы не можете проверить любой вариант в браузере, потому что без javascript вы не можете сделать PUT в браузере.

Ответ 2

~~Вариант № 1 в порядке, хотя, вероятно, перебор.~~ Параметр # 1 не отлично, потому что он не идемпотент.

Вариант № 2 - идея БАД. Это было бы неправильным использованием PUT. PUT следует использовать, прежде всего, когда полезная нагрузка данных запроса является непрозрачным блоком данных, обычно либо большим, либо иерархическим. Меньшие, неиерархические полезные значения имеют больше смысла как POST.

Также старайтесь избегать изменения состояния с помощью параметров запроса. Там нет ничего технически опасного, если это не запрос GET, но это не действительно RESTful.

В этом случае, что вы должны делать:

POST /players HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12

name=Gretsky

Это должно вернуть ответ 201 Created. (Существует исключение: если вы не создадите ресурс немедленно, и он может быть отклонен позднее, используйте вместо него 202 Accepted.)

Написание веб-службы REST, которая использует больше HTTP, чем POST и GET, должна выполняться только после чтения HTTP-спецификации. (Это очень полезное чтение.) Это правило немного слабее, если вы используете фреймворк, который принимает все решения для вас.

Ответ 3

Мое понимание операций REST заключается в том, что URL-адрес уникально идентифицирует ресурс, а тело запроса содержит представление ресурса. Учитывая это, сомнительно, действительно ли один из ваших вариантов RESTful.

Первым будет, считая, что ресурс называется "Игроки" и GET на этом ресурсе возвращает список игроков (я не буду задаваться вопросом, возвращает ли этот GET URL других ресурсов или нет... Филдинг сказал бы, что он должен с индивидуальными запросами получать данные о ресурсах).

Вторым было бы, считая, что тело запроса содержит информацию под названием "Грецкий". Однако это требует от вас внешних ключей.

Ответ 4

Используемый url должен идентифицировать ресурс в теле, либо компонентами пути, либо параметрами запроса, хотя я бы предпочел использовать компоненты пути для чего-то вроде имени или идентификатора. Тело должно быть представителем; тот, который вы PUT должен иметь тот же или похожий, что и вы, GET с одного и того же URL (или может получить, в случае нескольких форматов)

Пример №1 не подходит, потому что вы отправляете представление для одного игрока в URL-адрес для всех игроков. POST был бы более уместным в этом случае.

Пример # 2 был бы немного неуместным, если бы был расширен для всех полей, потому что тогда вы отправляли данные представления в URL.