Reszta projektu uri do zmiany statusu zasobu

Question

Mam zasób, który można uzyskać pod adresem URI /resources/{resource_identifier} i ma właściwość "status", która ma być dostępna. Zastanowiłem się nad kilkoma opcjami, które byłyby "najlepsze" lub "najbardziej relaksujące"?

działania Option One Append na URI i mieć klienta POST tych URI

/resources/{resource_identifier}/void  
/resources/{resource_identifier}/open  
/resources/{resource_identifier}/close 

To wygląda niezdarny choć.

---

Opcja druga Użyj param kwerendy w URI, a nie klienta PATCH do tych

/resources/{resource_identifier}?transition=void 
/resources/{resource_identifier}?transition=open 
/resources/{resource_identifier}?transition=close 

---

Opcji Trzy Korzystanie ładunek na życzenie i mieć klienta PUT

/resources/{resource_identifier} 

opcji ładowność:

{ ..., "status" :"void" } 
{ ..., "status" :"open" } 
{ ..., "status" :"close" } 

---

A może coś zupełnie innego?

Answer 1

Twoja druga opcja wygląda lepiej, ponieważ zachowujesz strukturę URL RESTful i nie dołączasz do niej metod w stylu RPC.

Dlaczego nie po prostu to zrobić:

PUT do /resources/:id i wysyłać dane transition=void z żądaniem.

Zachowuje się w taki sam sposób, jak w przypadku otrzymywania żądania POST, wystarczy pobrać dane z treści żądania.

Answer 2

Dlaczego nie "status" jako zasób. Możesz nim zarządzać. Załóżmy również, że powinien istnieć "status" utworzony w ramach tworzenia zasobów {resource_identifier} i istnieje już domyślna wartość dla statusu.

Następnie logika biznesowa polega jedynie na "zaktualizowaniu" statusu poprzez pozostałe połączenia i dlatego należy użyć "PUT".

aktualizowane Moving statusu do Put-Body

PUT: /resources/{resource_identifier}/status/ 

Body: {void | open | close } 

Answer 3

Pierwsza opcja nie jest wyraźnie odpoczynku; masz "działania" w URI i używasz POST, co ma na celu utworzenie nowego zasobu, którego najwyraźniej nie próbujesz zrobić.

Patrząc na format tylko URI na teraz. Opcja druga jest coraz lepsza, ale ciągi zapytań tego typu są bardziej dla danych odczytujących dane. Nic tak naprawdę nie powstrzymuje cię od zrobienia tego w ten sposób. Opcja trzecia ma najlepszy format URI, odwołuje się tylko do tego, do którego zasobu chcesz się odwołać.

Jeśli teraz rozważymy metodę żądania. W mojej książce jest to dość proste, zakładam, że status jest tylko jednym polem tego zasobu, więc jeśli wykonujesz tylko częściową aktualizację, łatasz zasób, a tym samym jest to metoda, której należy użyć. Przy braku szansy "stan" jest jedyną właściwością, a następnie zmiana statusu całkowicie zmienia zasób, a zatem PUT byłaby dopuszczalna; ale wątpię, czy tak rzeczywiście jest.

W obecnej postaci identyfikatory URI trzeciej opcji w połączeniu z użyciem PATCH są prawdopodobnie najlepszą opcją.

PATCH /resources/{resource_identifier} 

{ "status" :"close" } 

Oczywiście, można także łączyć z tym pojęciem narażając konkretnych atrybutów poprzez własny URI, jak gdyby były zasobem w sobie. Szczerze mówiąc, nie podoba mi się to, ponieważ wydaje się dziwne i działa tylko dla jednego atrybutu na raz. Mimo to, jeśli to jest to, czego chciał użyć, można mieć coś takiego:

PUT /resources/{resource_identifier}/status 

close 

---

Pamiętaj, że nie ma „prawo” sposób prowadzenia odpocząć, po prostu „nie złe” sposoby. To styl, a nie zbiór reguł.

Sugeruję również, że uważacie, że umiejętność przyjmowania wielu formatów jest ogólnie pożądaną cechą. W związku z tym pierwsza opcja wydaje się łatwiejsza w obsłudze. Możesz wziąć JSON, jak w przykładzie, lub zamienić go na XML <status>close</ status>, lub prostą parę wartości klucza status=closed itd.