Czym jest REST API? (#1)

REST API to jeden z tematów o których słyszał każdy programista, lecz inaczej wygląda to z jego pełnym zrozumieniem i praktycznym wykorzystaniem. Ta seria filmów ma na celu to zmienić. Pierwszy odcinek odpowiada na pytanie: Czym jest REST API?

[ciachostko]

skoro już o rest api mowa to chyba nie może zabraknąć... ( ͡° ͜ʖ ͡°)

[k.....k]

@ciachostko: humor IT ( ͡° ͜ʖ ͡°)

[comrade]

Nikt nie wie czym jest REST API, nie ma jednego oficjalnego standardu :)

Nawet nie wiadomo do końca jakie kody HTTP powinno zwracać w jakich sytuacjach i w jaki sposób obsługiwać błędy i powiadamiać o nich klienta.

To co przeciętne REST API robi z status kodami HTTP woła o pomstę do nieba. Te statusy są dobrze zdefiniowane w samym standardzie HTTP ale one zostały wymyślone po to by informować o stanie komunikacji

[comrade]

@vitek6:

Jeden rabin powie że robiąc PUT i nie podając wymaganego pola (albo popełniając jakiś inny błąd merytoryczny/logiczny, nie syntaktyczny) API powinno zwrócić HTTP 200, inny rabin powie że HTTP 400.

[krasnoludkolo]

@vitek6 w sumie to nie. Na poziomie http request jest poprawny. Niepoprawny jest na innej warstwie abstrakcji

[markee]

Api rest jest de best
W porownaniu do soapa ;)

[splatch]

@markee: oba podejścia mają blaski i cienie. REST jest o wiele prostszy przy modelowaniu zapytań natomiast SOAP jest o wiele bardziej restrykcyjny a przez to i uporządkowany.
Dodać, że REST czekał 10 lat na jako taki format jego opisu (openapi a wcześniej swagger bo wadl się nie przyjął).

Inna kwestia że REST to nie tylko RPC a cała filozofia w podejściu do tworzenia API.

[splatch]

@kilobit: chodzi o poziomy dojrzałości api restowych. Przy przerzuceniu wszystkiego z soap na rest w najbardziej ułomnym posejściu zamiast mieć jeden root do wszystkich wywołań operacji (getMovies, getActors) masz wiele (/movies, /actors).
Do tego momentu sprawa jest prosta, komplikacje pojawiają się w chwili gdy trzeba pobrać aktorów z danego filmu. Przy wsdl definiujesz operację getActorsByMovieId, natomiast przy prawidłowym reście powinno być /movies/:id/actors lub coś podobnego.

W praktyce widziałem bardzo niewiele

[sidneypl]

zarzucę klasykiem ( ͡° ͜ʖ ͡°)

[overment]

@sidneypl: nie znałem tego ( ͡° ͜ʖ ͡°)

[mcsQ]

api srapi

[LeftShift]

@Jossarian można nie używać, bo akurat do projektu nie pasuje, ale żeby nie znać już od lat jednego z popularniejszych standardów komunikacji, to trzeba naprawdę nie chcieć się rozwijać...

[Psychopathy_Red]

Właśnie miałem zadawać dokładnie to samo pytanie na mirko, a tu proszę :D

[overment]

@Psychopathy_Red: Jesteś czwartą osobą dziś, która mi to mówi :) Super że trafiłem w temat. Kolejny odcinek powinien być gotowy w niedzielę.

[overment]

@bociana_dziobie_szpak: z tej złej ( ͡° ʖ̯ ͡°)

[kowalzki]

to moze kilka uwag. 1) robiac taki fikmik nakezaloby sie zdecydowac kto jest odbiarca - programista ktiry konsumuje apu czy tworca api. i odpowiednio do tego dostosowqc tresc. 2) nie wiem skad wziales te zasady ale cacheowanie jest kwestia kompletnie niezwiazana z api. 3) jak przedstawiasz endpointy to warto powiedziec jak sie przekazuje payload w piszczegolnych metodach. 4) cacheable wymawia sie 'keszybl' z akcentem na pierwsza sylabe 5) dobrze by bylo dac

[overment]

@kowalzki: dzięki! Konkretny feedback :)

1) Faktycznie nie określiłem tego. Wziąłem pod uwagę dwa use case'y.
2) Sprzeczałbym się czy kompletnie nie związana z API, ale chyba rozumiem punkt widzenia.
3) To powiem w kolejnych filmach
4) Tak, mój angielski leży

[kowalzki]

@DBoss: proste pytanie - czy mozesz miec rest api bez cacheowania? mozesz. czy bedzie to dalej rest api? bedzie. dziekuje. kurtyna.

[b.....s]

95% tzw restowych api to po prostu API oparte o http które już przynajmniej stwierdziły, że soap nie jest rozwiązaniem problemów którym niby miał być. Ot idea starsza niż sam soap. W ujęciu modelu dojrzałości Richardsona, są one na poziomie zerowym. API na czwartym poziomie, implementujace hateoas, to szare kruki. Oczywiście teraz większość architektow twierdzi, że hateoas to mrzonka, ale sądzę, że dojdziemy do momentu w programowaniu, kiedy będziemy zawali sobie pytanie,

[o_40855]

kiedy będziemy zawali sobie pytanie, jak można było robić API inaczej

@bobsonjones: Raczej, jak można było na siłę dopasowywać coś, co z natury jest RPC, do jakiegoś wydumanego modelu, który po prostu rozmija się z potrzebami i w ogóle rzeczywistością.

[o_40855]

Dlaczego

@Goglez: Bo REST to po prostu glorified CRUD. Od tego mamy repozytoria w DDD, żeby ten "niskopoziomowy" sposób rozumowania zaenkapsulować. Ponad nimi mamy agregaty, encje, sagi, zdarzenia - obiekty, które poprzez swój interfejs wyrażają koncepcje biznesowe abstrahujące od prymitywów "create", "read", "update" i "delete". Obiekty domenowe nie eksponują zasobów, jak REST, ale funkcjonalności. Te funkcjonalności opakowuje się następnie w konkretne przypadki użycia - dawniej tworzono klasy zwane serwisami aplikacyjnymi,

[oink_oink]

filmik typu: wstep do wstepu o rest...

[j.....3]

@overment tu jeszcze bym zwrócił uwagę na to, że aktualizacja danej encji powinna się odbywać nie tylko przy pomocy PUT ale także PATCH. PUT w tym wypadku jest idempotenty, czyli aby zaktualizować np. nazwę użytkownika za każdym razem należy wysłać całą encję (cały obiekt użytkownika). Natomiast PATCH pozwala na przesłanie jedynie samego parametru "username".

Ten aspekt REST API (a raczej protokołu HTTP) jest najczęściej mylony i implementowany niepoprawnie.