Teoretycy REST
2010-03-03
Projektuję API do e-usługi. Chciałem się kierować filozofią REST (REpresentational State Transfer), żeby było intuicyjnie i nieskomplikowanie.
Szybki przegląd artykułów na temat REST w Internecie utwierdza mnie w przekonaniu, że o REST piszą głównie teoretycy. Bez końca ciągną się dywagacje czy do „/company/employee” stosuje się POST czy PUT, za to niemal nikt nie zastanawia się nad wersjonowaniem API i tym gdzie umieścić numer wersji.
jako nagłówek. to metadane przecież.
Bartosz: A może jednak w URI? Bo: Czy będę mógł robić load-balancing na podstawie nagłówków? Czy będę mógł w kolejnej wersji API zmienić kompletnie strukturę wszystkich URI?
a dlaczego miałbyś robić load balancing na podstawie nagłówków? różne maszyny obsługujące różne wersje api? średni pomysł.
zmienianie struktury uri - z całą pewnością bardziej niż podczas umieszczania wersji api w uri, choć sensowność takiego posunięcia to już inna bajka.
idea rest jest stosunkowo prosta - i naprawdę (poza tym jednym fikcyjnym problemem) nie widzę nic "nieżyciowego" w konktekście pisania restfulowego webservice-u.
Ja tam unikam nagłówków. Wtedy, przynajmniej dla GETów, można sobie szybko testować przeglądarką czy zwraca co trzeba.
I fakt, wersjonowanie jest zagadnieniem, podobnie, jak autoryzacja i sygnalizowanie błędów.
sygnalizowanie błędów - odpowiedni kod http, a do tego wyjaśnienie błędu w jsonie/xmlu/czymkolwiek.
Wawrzek - http://hurl.it/ - możesz sobie postawić u siebie lokalnie.
nie wymyślajmy świata od nowa, http ma tyle wbudowanych solidnych mechanizmów, które ludzie - nie wiadomo dlaczego - starają się obejść...
Bartosz: ależ ja nic się nie staram obchodzić. Wręcz przeciwnie — starałem się dowiedzieć jak będzie najbardziej koszernie i miałem z tym kłopoty. A różne maszyny obsługujące różne wersje API to nie jest „średni pomysł”, to może wręcz być wymaganie w przyszłości. Podobnie z „sensownością” zmian w strukturze URI.
A REST-owate webserwisy są proste gdy pisze się przykład z company i employee. W życiu potrafi być gorzej.
Jan - nie ma żadnego reverse proxy które mogłoby działać na podstawie nagłówków? ciężko mi w to uwierzyć.
odnośnie prostoty restfulowych webservice-ów - owszem, nie jest to proste zadanie, kiedy aplikacja nie działa restfulowo. jeśli jednak aplikacja działa już w ten sposób, to większość problemów napotykasz nie podczas tworzenia API, tylko podczas tworzenia właściwej aplikacji. a nagrodą za trzymanie się konwencji jest m.in. banalne tworzenie API.
Bartosz: nie wiem, czy jest takie proxy. Chodziło mi o to, że być może lepiej wkodować wersję API w URI, bo w ten sposób z pewnością każdy load balancer będzie w stanie przekierowywać na tej podstawie. Będzie mniej purystycznie, za to bardziej praktycznie.
A co do prostoty przykładów REST w sieci to nadal utrzymuję, że większość jest wymyślona pod potrzeby REST. Widać to chociażby po tym, że przykłady są odpowiednikiem bazy danych, gdzie pokazuje się robienie create, read, update, delete. A przecież często gdy piszę aplikację to eksponuję usługę, a nie zasób. Przykładem może być wyszukiwarka — gdzie tu zasób? Gdzie CRUD?
Jan - przydałoby się tu przysłowie o młotku i gwoździach :) tam gdzie da się zastosować REST - stosuj, tam gdzie się nie da - nie stosuj. inaczej to będzie sztuka dla sztuki. a gdyby się uprzeć, to /company/search?q="foo" też jest RESTfulowe.