Какова рекомендуемая / эффективная полезная нагрузка запроса для метода REST PUT? - PullRequest
Новая
       16

Какова рекомендуемая / эффективная полезная нагрузка запроса для метода REST PUT?

5 голосов
/ 21 ноября 2008

Я вижу два типа примеров в разных местах. Один использует поля формы, такие как

curl -X PUT -d "phone = 123.456.7890" "http://127.0.0.1/services/rest/user/123"

, а другой использует XML-контент, такой как (некоторые варианты), этот

эхо " 123 123.456.7890 " | curl -X PUT -d @ - "http://127.0.0.1/services/rest/user/"

Кажется, что использование полей формы обладает преимуществом краткости и четкой идентификации намерений клиента путем нацеливания только на измененные поля, но затрудняет обращение к "более глубоким" метаданным.

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

Есть ли лучшая практика или даже более распространенная практика?

Ответы [ 3 ]

2 голосов
/ 24 ноября 2008

Это может быть что-то вроде JSON (P)? (Я не уверен в точном синтаксисе): 

$ echo '{user: {id: 123, phone: 123.456.7890}}' |\
> curl -X PUT -d @- 'http://127.0.0.1/services/rest/user/'

Или 

$ echo '{phone: 123.456.7890}' |\
> curl -X PUT -d @- 'http://127.0.0.1/services/rest/user/123.json'
0 голосов
/ 24 ноября 2008

Хороший вопрос! Я не знаю конкретной передовой практики или обычной практики. Но я хочу отметить, что вопрос на самом деле не о полях формы или XML, а о частичном представлении или полном представлении. Вы кратко описали практические различия между ними. Один аспект вопроса - кто несет ответственность за определение того, что изменилось: клиент или сервер.

Гибридный вариант - это какой-то формат, в котором клиент может указать, что именно изменилось , используя некоторый синтаксис для указания на «более глубокие» метаданные, такие как XPath или JSONpath, вместе с новым значением. .

0 голосов
/ 21 ноября 2008

Во втором примере URL не относится к конкретному ресурсу, поэтому ИМХО это не RESTful.

Если вы исправите это, выбор сводится к форме и кодированию XML.

Если вам нужны структурированные и расширяемые данные, тогда может пригодиться XML: 

<phone type="work, mobile"><num>555-555</num><ext>123</ext></phone>

но не обязательно: 

phone=555-555&phone-ext=123&phone-type=work&phone-type=mobile

Многие пользователи API могут неправильно понимать кодировку XML, им трудно понять, что такое косвенное обращение к пространству имен, поэтому кодирование форм может быть лучше для широкой аудитории.

...