Wojciech Sznapka – software development blog

Superior thinking dmoesntrtaed above. Thanks!

Interesuje mnie, jak w architekturze REST-owej można realizować akcje typowe dla SOA albo dla “normalnej” aplikacji webowej. Swoją drogą REST i SOA to chyba niedokładnie to samo podejście do realizacji usług sieciowych – w części literatury przeciwstawia się właśnie podejście RESTful klasycznemu SOA, opatrując ten pierwszy akronimem ROA).

Kontynuując przykład podany w prezentacji – jeżeli chcę oznaczyć dany ticket jako zamknięty i skorzystać z aplikacji poprzez jej RESTowy interfejs, to czy powinienem pobrać cały obiekt ticketa (GET tickets/{id}), zmodyfikować go (np. ustawiając odpowiednią wartość we własności statusu) i zapisać go (PUT tickets/{id})? Czy w przypadku ograniczenia możliwości zmiany stanu (np. przez określony z góry cykl życia ticketu) ograniczy mnie tylko walidacja po stronie serwera (w odpowiedzi na PUT dostanę listę błędów walidacji)? Rozumiem, że dodanie akcji pod URI tickets/{id}/mark-as-closed nie jest już zbytnio REST-owe, bo taki URI nie reprezentuje żadnego konkretnego zasobu?

Druga kwestia – co z nietypowymi zapytaniami o większą kolekcję zasobów? Pobranie wszystkich ticketów z aplikacji jest raczej proste (GET tickets). Ale co w przypadku, gdybym chciał pobrać tylko tickety danego użytkownika? Jak można przekazać dodatkowe parametry dla takiego grupowego zapytania? Tutaj ponownie lista ticketów danego użytkownika nie reprezentuje jakiegoś pojedynczego zasobu, ale pewną grupę zasobów. Czy w takim przypadku powinno być zdefiniowane nowe URI (np. GET tickets/by-user/{user_id}), czy przekazać dodatkowe parametry (np. GET tickets/?user={user_id})? Na ile jest to podejście RESTful?

Słusznie, ROA to bardziej RESTfulowe SOA (czyli nie realizowane jako WSDL czy podobne i skupiające się na zasobach, a nie na akcjach). Rozwiązania wydają się rozsądne i zgodne z ideą.

Jeszcze jedna kwestia – jak rozwiązać kwestię zasięgu serializacji przy zwracaniu obiektu (np. czy z pobieranym ticketem zwracać od razu użytkownika, który go utworzył, czy traktować go jako osobny zasób)? Czy można (a właściwie – czy powinno się) tworzyć RESTowe metody z różnymi zakresami serializacji? Jeżeli przy pobieraniu zwracane są jakieś obiekty powiązane, to czy muszą one być również odesłane przez klienta przy realizacji zapytania typu PUT/POST?