Robię sobie webapi do składania zamówień. Jednym ze scenariuszy jest, że na niektóre zamówienia musi być potwierdzenie managera, że zamówienie zostanie przekazane do produkcji. Odpowiada za to pole IsAccepted w klasie Order.
Ogólnie wyglada to tak, że klient tworzy zamówienie. Trafia ono do opiekuna klienta. Opiekun dodaje do takiego zamówienia jeszcze dodatkowe informacje poprzez akcje webapi Update. Jeśli te dodatkowe dane spełniają jakieś tam wymagania, to zamówienie trafia do managera, który może je albo zaakceptować, albo odrzucić. Z technicznego punktu widzenia polega to tylko na przypisaniu do pola IsAccepted wartości true lub false.
Pytanie polega na tym, czy taką akceptację wykonać też przez akcję Update kontrolera, czy swtorzyc do tego osobną akcję lub dwie, coś w stylu AcceptOrder(), DeclineOrder(), w których będzie się działo jedynie zatwierdzenie lub odrzucenie? Jak to się powinno robić?
Na to nie ma jednoznacznej odpowiedzi. Gdyby dało się na wszystko co związane z pisaniem aplikacji jasno stwierdzić jak się to powinno robić to by nie było tyle burzliwych dyskusji :) Purysta REST powie Ci że musisz wystawić PUT endpoint, purysta task-driven powie Ci że powinien to być odpowiednio nazwany endpoint opisujący akcję, a to czy będzie to POST czy PUT to nie ma większego znaczenia. Purysta domenowy doda do tego że taka aktualizacja modelu domenowego musi się odbyć poprzez odpowiednią metodę tegoż modelu, która będzie weryfikować czy w ogóle można tą wartość zmienić.
Wszystko zależy od szerszej perspektywy- czy Twój system ogółem jest dosyć prostym CRUDem, czy może masz tam złożone procesy i dodatkowy narzut pracy przyniesie korzyści długoterminowo? Jeśli to pierwsze to powiedział bym aby kierować się zasadą KISS (keep it simple stupid) i po prostu potraktować tę operację jako aktualizację całego modelu. W przeciwnym razie wystawiłbym to jako dedykowany endpoint, przyjmujący tylko wymagane pola (czyli np. flaga IsAccepted) i aktualizujący tylko te konkretne pola w modelu/encji.
Ja bym zrobił endpoint z parametrem (np. true/false). Taki endpoint możesz łatwo zabezpieczyć przed nieupoważnionym wywołaniem. Możesz dać do niego dostęp jedynie managerom.
Ja w takim przypadku bym zrobił po prostu endpoint w stylu /orders/{id}/accept.