Jak zwrócić wygenerowany identyfikator w RESTful POST?

Question

Powiedzmy mamy usługę, aby dodać nowy hotel:

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

A potem mamy otrzymać:

> GET /hotel 

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

pytanie, co mamy powrócić do początkowego tworzenia postu? Chcemy zwrócić identyfikator (wygenerowany na serwerze) w celu "odniesienia" do nowego zasobu, ale nie chcemy zwracać wszystkich danych hotelowych, ponieważ w naszym przypadku jedno z pól danych jest płaskim plikiem ~ 300 000 .

więc należy po prostu wrócić:

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

Albo należy zwrócić cały obiekt:

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

??

Jestem zainteresowany najlepszą, spokojną praktyką.

Uwaga: ten powiązany post mówi więcej o tym, co zwrócić, ale mniej o tym, jak go zwrócić.

Answer 1

Zwraca kod statusu 201 - Utworzono i wpisano adres URL w nagłówku Lokalizacja. Nie musisz w ogóle zwracać ciała.

Answer 2

REST dotyczy wszystkiego, co URL do zasobów.

Najlepszą praktyką RESTful jest zwrócenie adresu URL używanego do uzyskania dostępu do właśnie utworzonego zasobu.

Nie zwrócę całego dokumentu. O ile nie jest to ważne dla protokołu z jakiegoś powodu (np. Serwer może zmienić dane, które klient przesyła, a klient chce potwierdzić, że wszystko jest w porządku). Jeśli nie jest to ważne, klient zna już dane.

Jeśli zwrócisz tylko identyfikator, klient nie będzie wiedział, co z nim zrobić. Zwrócenie adresu URL umożliwi klientowi kontynuowanie interakcji REST z serwerem (prawdopodobnie poprzez pobranie dokumentu opisu usługi). Nie oznacza to, że nie można zwrócić identyfikatora wraz z adresem URL. Ale adres URL, ponieważ jest to system internetowy, jest najważniejszą informacją, jaką możesz poznać. Ponadto ID może być czymś, czego potrzebujesz wewnętrznie dla twojego zaplecza, a nie czymś, o czym klient powinien się martwić.

EDYTOWANIE:
Co do tego, czy powinieneś zawijać zwrócony URL w XML, to naprawdę zależy od twojego protokołu. Jeśli uważasz, że możesz chcieć zwrócić inne dane w przyszłości, XML będzie bardziej rozważny. Posiadanie nazwanego formatu pliku pozwoliłoby na lepszą wersję usług (poprzez zmianę nagłówka typu dokumentu). Ale możesz po prostu zwrócić adres URL.

Answer 3

Jedną z zalet zwracania nagłówka Location i rzeczywistej treści podmiotu w odpowiedzi jest to, że klient może otrzymać wynikową reprezentację w jednym obiegu do serwera. AtomPub robi to, na przykład.