Как вернуть сгенерированный идентификатор в RESTful POST? - PullRequest
Новая
       19

Как вернуть сгенерированный идентификатор в RESTful POST?

28 голосов
/ 26 октября 2009

Допустим, у нас есть сервис для добавления нового отеля: 

> POST /hotel
> <hotel>
>   <a>aaa</a>
>   <b>aaa</b>
>   <c>aaa.......this is 300K</c>
> </hotel>

И тогда мы получаем: 

> GET /hotel

< HTTP/1.1 200 OK
< <hotel>
<   <a>aaa</a>
<   <b>aaa</b>
>   <c>aaa.......this is 300K</c>
< </hotel>

Вопрос в том, что мы возвращаем для первоначального создания POST? Мы хотели бы вернуть идентификатор (сгенерированный на сервере) для «ссылки» на новый ресурс, но мы не хотим возвращать все данные отеля, так как в нашем случае одно из полей данных представляет собой плоский файл размером ~ 300 КБ .

Так что вы должны просто вернуться: 

< HTTP/1.1 200 OK
< <hotel>
<   <id>123</id>
< </hotel>

Или вы должны вернуть полный объект: 

< HTTP/1.1 200 OK
< <hotel>
<   <id>123</id>
<   <a>aaa</a>
<   <b>aaa</b>
>   <c>aaa.......this is 300K</c>
< </hotel>

??

Я заинтересован в спокойной лучшей практике.

Примечание: этот связанный пост говорит больше о том, что вернуть, но меньше о том, как его вернуть.

Ответы [ 3 ]

41 голосов
/ 26 октября 2009

Верните код состояния 201 - Создан и поместите URL в заголовок Location. Тебе вообще не нужно возвращать тело.

14 голосов
/ 26 октября 2009

REST - это URL-адреса ресурсов.

Лучшая практика RESTful - возвращать URL-адрес, используемый для доступа к только что созданному ресурсу.

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

Если вы вернете только идентификатор, клиент не будет знать, что с ним делать. Но возвращение URL-адреса позволит клиенту продолжить взаимодействие REST с сервером (предположительно, получив документ с описанием услуги). Это не означает, что вы не можете вернуть идентификатор вместе с URL. Но URL, потому что это веб-система, является наиболее важной частью информации, которую вы можете знать. Кроме того, идентификатор, скорее всего, будет тем, что вам нужно внутри вашей бэкэнда, а не чем-то, о чем клиенту придется беспокоиться.

EDIT:
Относительно того, следует ли вам обернуть возвращаемый URL в XML, это действительно зависит от вашего протокола. Если вы думаете, что вы захотите вернуть другие данные в будущем, XML будет более разумным. Наличие именованного формата файла позволит вам лучше управлять версиями ваших служб (изменяя заголовок типа документа). Но вы можете просто вернуть URL.

10 голосов
/ 31 октября 2009

Единственным преимуществом возврата заголовка Location и фактического тела объекта в ответе является то, что клиент может получить результирующее представление за один прием в оба конца на сервер. AtomPub делает это, например.

...