Dlaczego REST API wcale nie jest REST-In-Peace

Jakiś czas temu w Sieci zaczęły mnożyć się artykuły, że odkąd narodził się GraphQL, to REST jest już R.I.P., czyli spoczywa w pokoju. Jako firma technologiczna wystawiająca multum REST API, dzięki którym informacje gospodarcze uzupełniają systemy naszych Klientów, postanowiliśmy przyjrzeć się bliżej plotkom i oficjalnie porównać obie technologie, niczym dwie smakowicie wyglądające drożdżówki, z których wpakować do buzi można tylko jedną.

Co to jest REST i GraphQL — szybkie wprowadzenie

(pomiń jeśli technologicznie ogarniasz i nie potrzebujesz, żeby mówić do Ciebie jak do 5-latka)

Świat REST i GraphQL krąży wokół jednego zadania: komunikować. Mamy komputer X jakiegoś człeka i mamy serwer i żeby pierwszy mógł rozmawiać z drugim (czyli dowiedzieć się co u niego słychać, zapytać o pogodę itp.), potrzebny jest jakiś rodzaj komunikacji.

Każdy z nich spełnia swoje zadanie nieco inaczej.

REST (Representational State Transfer) to rodzaj architektury API, którego główną zaletą jest to, że nie wymaga od programistów pisania tysięcy linii kodu. W zamian bazuje głównie na architekturze wygodnych w użyciu URL. Liczba tych URL będzie rosła wraz z systemem. Nie potrzebujemy tu definiować obiektów — elastycznie wykorzystujemy linki, tam gdzie są one potrzebne.

GraphQL to również podobnie jak REST, sposób komunikowania się z serwerem API, z tą różnicą, że tutaj mamy tylko jeden adres, do którego możemy się zwracać o dane, a zamiast URL wykorzystujemy gotowe obiekty. Najpierw definiujemy obiekty, a potem używamy ich w systemie.

Podsumowując: API musi być przewidywalne. Program musi wiedzieć o co może zapytać i jaką odpowiedź dostanie zwrotnie. Rolą REST i GraphQL jest właśnie zdefiniowanie tej przewidywalności i umożliwienie skutecznej, dwustronnej komunikacji.

REST vs. GraphQL — podobieństwa i różnice

Podobieństwa:

• oba posiadają koncept (definicję) źródła i są w stanie różnicować ID dla źródeł,
• oba odpowiadają na zapytania HTTP GET poprzez URL,
• oba mogą zwracać dane w formacie JSON.

Różnice:

• w REST punkt końcowy, czyli endpoint, jest tożsamy z obiektem i odgórnie definiuje w jaki sposób odbieramy z niego informacje. W GraphQL obiekt i sposób w jaki się z nim komunikujemy to dwie oddzielne rzeczy,
• W REST to serwer definiuje rozmiar i kształt zwracanych danych. W GraphQL serwer definiuje jakie są dostępne rodzaje źródeł, ale to Klient formułuje zakres danych, który chce uzyskać w odpowiedzi i w jakiej formie,
• gdyby patrzymy na architekturę REST API (np. przeglądając dokumentację API) od razu rzuca się w oczy, że jest ona linearna— mamy listę punktów, które o coś możemy zapytać. Jedyne pytanie jakie przychodzi nam do głowy, to “który z tych punktów mam o coś zapytać?”. W GraphQL tej liniowości nie znajdziemy, ponieważ odpytujemy za pomocą gotowych obiektów zdefiniowanych wcześniej w danych schemacie. Innymi słowy: w REST odpytujemy różne źródła po kolei, korzystając z linków, a w GraphQL możemy jednym zapytaniem (wywołującym dany obiekt) odpytać jednocześnie kilka źródeł ujętych w schemacie.

Skąd wzięło się tak wielkie zauroczenie GraphQL?

Naszym zdaniem, przede wszystkim z wygody użycia. Mamy gotową listę obiektów, tworzymy schemat i dalsze utrzymanie czystości kodów nie wymaga tyle trudu. Nie to, co z REST, gdzie im bardziej rozbudowujemy system, tym więcej URL musimy dodać. Wiadomo — wygoda zawsze ma znaczenie.

Co więcej, GraphQL likwiduje problem projektowania wielu różnych zapytań pomiędzy źródłami, by finalnie zebrać potrzebne do uzyskania odpowiedzi dane. Skalowanie jest tu dużo prostsze niż w przypadku REST.

No, ale REST ma coś, czego nie ma GraphQL…

I jest to nie tylko uniwersalność, o której mówi się jako drugim imieniu REST. Jest to szybkość.

GraphQL to obiektowe myślenie o API. Mamy załóżmy 20 produktów i 100 Klientów. API tu śmiga fajnie, fakt. Ale co z sytuacją, gdy — jak w przypadku naszych rozwiązań — Klient chce otrzymać już aktualną odpowiedź, która wymaga odpytania kilkudziesięciu różnych źródeł, a do tego przetworzenia tych danych i dopiero podania ich Klientowi? A co więcej każdy z Klientów zadaje zazwyczaj zupełnie inne pytanie i ma potrzebę otrzymać różne zestawy danych z wielu źródeł?

Dzięki REST mamy bazę i mamy osobny endpoint dla każdego Klienta. Każdy wszak pyta o coś innego, a niektórzy potrzebują aktualizacji informacji real-time przez co ich rozwiązanie obudować trzeba kilkoma usługami dookoła, które dane te aktualizują np. z CEIDG czy KRS. Gdy Klient zadaje pytanie, wystarczy, że odpytamy bazę. W GraphQL mając jeden obiekt (np. informacja “firma”), musielibyśmy odpytać po kolei każde API każdego źródła i dopiero skleić odpowiedź…

Podsumowując: GraphQL z pewnością jest wygodne i świetne, gdy mamy schemat i schemat ten powielamy. Ale REST jest szybsze i zdecydowanie lepiej sprawdza się przy spersonalizowanych rozwiązaniach.

Minie jeszcze sporo czasu zanim REST będzie R.I.P.