Czy może ktoś mi na chłopski rozum wyjaśnić czym się różni WEB API od REST API?
0
4
REST dotyczy tego jakiego rodzaju operacje udostępniamy (tj. myślimy raczej o zasobach - resources, które można pobierać, usuwać, modyfikowac), web/HTTP API mówi jedynie o rodzaju interfejsu, którego korzystamy.
Chyba, że pytasz w kontekście ogłoszeń o pracę - wtedy nie ma żadnej różnicy.
2
Jak dla mnie WEB API to coś co wystawiamy na świat po internetach krótko mówiąc. Do takiego czegoś się może zaliczyć i SOAP i REST. (jak się mylę to niech mnie ktoś poprawi)
Jeżeli chodzi o REST API to już chodzi o coś konkretnego czyli w tym przypadku o REST. Czym jest REST API to można znaleźć w 30 sekund.
2
Kiedyś Rest stanowiło pewien standard i wskazówki, jak projektować API.
Teraz te terminy stały się bardzo popularne, a ponieważ stały się popularne, to wielu ludzi dopowiada sobie do niego nieistniejące cechy i poprawia względem swojej woli; także w dobie dzisiejszego postępu tak na prawdę nie ma między nimi różnicy; ponieważ te terminy stały się tak rozmyte, że jak spytasz 1000 ludzi o to czym jest Rest API to dostaniesz 1000 odpowiedzi.
1
REST to sposób projektowania WEB API, to architektura. Poczytaj o https://martinfowler.com/articles/richardsonMaturityModel.html, bo to dobrze tłumaczy zmianę podejścia: zamiast operacji modelujemy zasoby.
Oczywiście swego czasu był hype na REST API przez co sama idea się rozmyła. Często można było usłyszeć (teraz już raczej nie, chociaż kto wie), że WEB API to SOAP i XMLe a REST to jsony, choć to nie ma nic wspólnego oprócz tego, że JSON jako format zaczął stawać się popularny w tym samym czasie jak REST. Inna sprawa to fakt, że REST jest trochę jak komunizm: idea szczytna, ale nigdy się nie udaje do końca przez to, że ciężko wszystko zamodelować jako zasoby. Często zrobienie jakiegoś patha jako POST /doSomething jest prostsze i czytelniesze do ogarnięcia a przecież to jest naczelna idea stojąca za restem.
0
JSON jako format zaczął stawać się popularny w tym samym czasie jak REST.
JSON stał się popularny, bo to jakby natywny zapis obiektów w JS ;) Java Script Object Notation. Po prostu wygodniej było przeglądarkom odbierać dane w tym formacie i już.
No i jeszcze różnica pomiędzy REST a SOAP jest taka, że SOAP to protokół, gdzie REST działa na protokole HTTP. Jest też luźniejszy względem SOAPa.
REST jest trochę jak komunizm: idea szczytna, ale nigdy się nie udaje do końca przez to, że ciężko wszystko zamodelować jako zasoby.
No nie zgodzę się. Popularność go względem właśnie SOAPa polegała głównie na tym, że można było szybciej zrobić API. To bardziej SOAP jest jak komunizm - jeden słuszny w jeden sposób :D ;)
Taka jeszcze uwaga. Teraz chyba coraz popularniejsze staje się GraphQL. Osobiście nie używałem, ale brzmi fantastycznie, bo nie zamykamy się na konkretne metody.
0
JSON stał się popularny, bo to jakby natywny zapis obiektów w JS ;) Java Script Object Notation. Po prostu wygodniej było przeglądarkom odbierać dane w tym formacie i już.
@.andy: Mi głównie chodzi o format używany w komunikacji backend <-> backend. Oczywiście JS i dobry design to na pewno mocne katalizatory, które pozwoliły wybić się temu formatowi
No i jeszcze różnica pomiędzy REST a SOAP jest taka, że SOAP to protokół, gdzie REST działa na protokole HTTP. Jest też luźniejszy względem SOAPa.
Dwa zadania: zaprojektuj mi logowanie użytkownika i skomplikowane zapytanie typu search, gdzie request jest spory (kilkadziesiąt kb) i ma skomplikowaną strukturę drzewiastą. Czas 5 sekund. W SOAPie jest to trywialne. W RESCie musisz walczyć z protokołem i reprezentowaniem wszystkiego jako zasób
0
Dwa zadania: zaprojektuj mi logowanie użytkownika i skomplikowane zapytanie typu search, gdzie request jest spory (kilkadziesiąt kb) i ma skomplikowaną strukturę drzewiastą. Czas 5 sekund. W SOAPie jest to trywialne. W RESCie musisz walczyć z protokołem i reprezentowaniem wszystkiego jako zasób
Chyba dlatego powstał GraphQL. Wiadomo nie ma jednego młotka na wszystkie gwoździe, aczkolwiek są tacy co próbują :D ;)
1
.andy napisał(a):
Taka jeszcze uwaga. Teraz chyba coraz popularniejsze staje się GraphQL. Osobiście nie używałem, ale brzmi fantastycznie, bo nie zamykamy się na konkretne metody.
Hype na GraphQL chyba już się skończył. Nie słyszałem żeby ktoś coś mówił o nim ostatnio na konferencjach, chociaż faktem jest że ostatnio byłem na mniejszej ilości konferencji i meetupów :P
Z tego co zrozumiałem GraphQL to jego głównym zadaniem było oszczędzanie internetu. Zamiast wysyłać wszystkie pola w encji możesz sobie ograniczyć odpowiedź tylko do pól potrzebnych. Miało to być rozwiązanie problemu wolnego internetu na mobilkach. W dodatku IMHO przeinżynierowane
Mając REST też można coś takiego zrobić, albo mając osobne endpoiny dedykowane pod mobilki, albo mając przełącznik lub parametr pozwalający podać zwracane pola. Implementacja tego wygląda strasznie, ale GraphQL też trzeba zaimplentować sobie w większości ręcznie (z tego co czytałem bo nigdy tego cuda nie użyłem)
1
KamilAdam napisał(a):
.andy napisał(a):
Taka jeszcze uwaga. Teraz chyba coraz popularniejsze staje się GraphQL. Osobiście nie używałem, ale brzmi fantastycznie, bo nie zamykamy się na konkretne metody.
Hype na GraphQL chyba już się skończył. Nie słyszałem żeby ktoś coś mówił o nim ostatnio na konferencjach, chociaż faktem jest że ostatnio byłem na mniejszej ilości konferencji i meetupów :P
Racja; ale ja to bym sie raczej Hypem nie kierowal przy wyborze technologii ani w swoich opiniach, nt tego czy technologia jest dobra czy tez nie.
Z tego co zrozumiałem GraphQL to jego głównym zadaniem było oszczędzanie internetu. Zamiast wysyłać wszystkie pola w encji możesz sobie ograniczyć odpowiedź tylko do pól potrzebnych. Miało to być rozwiązanie problemu wolnego internetu na mobilkach. W dodatku IMHO przeinżynierowane
No tak, to byl jeden z celow, ale byly tez inne, czyli przystosowanie interfejsu bardziej pod aktualne potrzeby i pod SPA. Kiedy w necie dominiowaly MPA i widoki na Serverze REST byl oczywistym wyborem; teraz kiedy jest coraz wiecej SPA i appek z Service Workerami to sie zmienia.
Mając REST też można coś takiego zrobić, albo mając osobne endpoiny dedykowane pod mobilki, albo mając przełącznik lub parametr pozwalający podać zwracane pola. Implementacja tego wygląda strasznie, ale GraphQL też trzeba zaimplentować sobie w większości ręcznie (z tego co czytałem bo nigdy tego cuda nie użyłem)
Wiadomo ze majac kazda technologie mozna zrobic z niej co chcesz, mozna np napisac apke desktopowa w PHP; pytanie tylko jak odpowiednia jest do tego celu.
1
TomRiddle napisał(a):
KamilAdam napisał(a):
.andy napisał(a):
Taka jeszcze uwaga. Teraz chyba coraz popularniejsze staje się GraphQL. Osobiście nie używałem, ale brzmi fantastycznie, bo nie zamykamy się na konkretne metody.
Hype na GraphQL chyba już się skończył. Nie słyszałem żeby ktoś coś mówił o nim ostatnio na konferencjach, chociaż faktem jest że ostatnio byłem na mniejszej ilości konferencji i meetupów :P
Racja; ale ja to bym sie raczej Hypem nie kierowal przy wyborze technologii ani w swoich opiniach, nt tego czy technologia jest dobra czy tez nie.
Rajca że kierowanie się hypem jest zle. Chodziło mi konkretnie o to że andy napisał że "Teraz chyba coraz popularniejsze staje się GraphQL". No ja tego nie widzę, ale oczywiście nie jestem wszędzie żeby widzieć wszystko :)
Z tego co zrozumiałem GraphQL to jego głównym zadaniem było oszczędzanie internetu. Zamiast wysyłać wszystkie pola w encji możesz sobie ograniczyć odpowiedź tylko do pól potrzebnych. Miało to być rozwiązanie problemu wolnego internetu na mobilkach. W dodatku IMHO przeinżynierowane
No tak, to byl jeden z celow, ale byly tez inne, czyli przystosowanie interfejsu bardziej pod aktualne potrzeby i pod SPA. Kiedy w necie dominiowaly MPA i widoki na Serverze REST byl oczywistym wyborem; teraz kiedy jest coraz wiecej SPA i appek z Service Workerami to sie zmienia.
To ciekawe, nie znam się na pisaniu SPA. Możesz powiedzieć dlaczego GraphQL jest lepszy dla SPA niż REST?
1
KamilAdam napisał(a):
No tak, to byl jeden z celow, ale byly tez inne, czyli przystosowanie interfejsu bardziej pod aktualne potrzeby i pod SPA. Kiedy w necie dominiowaly MPA i widoki na Serverze REST byl oczywistym wyborem; teraz kiedy jest coraz wiecej SPA i appek z Service Workerami to sie zmienia.
To ciekawe, nie znam się na pisaniu SPA. Możesz powiedzieć dlaczego GraphQL jest lepszy dla SPA niż REST?
Again, to tylko moja opinia, dokonaj swojego rachunku sumienia.
Ale moim zdaniem, kiedy mamy aplikację MPA, to łatwiej jest stworzyć "wszystko jako zasób", bo każdy submit formularza robi reload, więc faktycznie łatwiej jest zbudować stronę zasobami.
Kiedy robimy SPA; raczej ciężko jest reprezentować wszystko zasobami, taki przykład, to np wypełniamy pole i leci Ajax z walidacją, żeby sprawdzić czy pole przechodzi walidację czy nie; noi jak to zaprezentujesz w REST? Stworzyć zasób i zaraz go usunąć? Czy może zrobić geta na wymyślony zasób GET /valid-usernames i jak dostaniesz 200 to jest valid, a 404 to jest invalid? No ciężko coś wymyślić sensownego. Z mojego doświadczenia ludzie albo olewają całkiem rest i robią GET /validate, co nie jest restowe; albo starają się za wszelką cenę zrobić żeby call wyglądał jak zasób; tylko one wtedy przypomniają takie "phantomowe" zasoby, które nie tak do końca followują rekomendacje. Czasem walidację da się napisać całkiem na froncie; ale czasem nie. Ja nie wpadłem jeszcze na pomysł jak takie API zaprojektować Restowo; a może też nie znalazłem odpowiedniego źródła.
Albo też może muszę się dokształcić.
Więc moim zdaniem REST nie jest tak dobrze dopasowany do current standardów.