Archiwum kategorii: Integracje

GraphQL – Pobieraj tylko to, co chcesz!

Czy zdarzyło Wam się kiedyś, że zwracaliście w API dane, które nie zawsze były wykorzystywane, a jedynie przydawały się w konkretnych sytuacjach? Na przykład: potrzebowaliście listy przedmiotów tylko po nazwie, a API zwraca dodatkowo kategorię oraz powiązane przedmioty, które nie są potrzebne w danej sytuacji, jednak inne miejsca w systemie z nich korzystają (over-fetching)? Albo wręcz odwrotnie – mieliście zbyt mało danych? Przez co, celem wyświetlenia listy produktów, musieliście wykonywać kolejne requesty, by pobrać informacje o powiązanych produktach (under-fetching)?

Możemy w takiej sytuacji tworzyć dedykowane endpointy lub też parametryzować (w zależności od interesujących nas informacji), ale zarządzanie takim API może stawać się z czasem coraz bardziej uciążliwe i nieefektywne.

GraphQL

Na szczęście z pomocą przychodzi nam opracowany przez firmę Facebook silnie typowany język zapytań GraphQL. Intuicyjna składnia GraphQL pozwala na pobieranie danych (Query), ich edycję i wstawianie (Mutation) oraz obserwowanie zmian w czasie rzeczywistym (Subscription). Język ten pozwala dokładnie określić jakie dane nas interesują na wyjściu, jak głęboko chcemy pobierać obiekty powiązane ze sobą oraz co dokładnie chcemy modyfikować.

Przykłady

Tworzymy typ “Product”, który posiada nazwę, powiązane produkty oraz kategorię. Jest on wykorzystany w domyślnym typie “Query” – wymaganym do działania. Tak stworzony schemat pozwala nam na pobranie wszystkich produktów i produktów powiązanych, wraz z kategoriami.

type Query {
  allProducts: [Product]!
}

type Product {
  id: ID
  name: String
  related: [Product]!
  categories: [Category]!
}

type Category {
  id: ID
  name: String
}

Spróbujmy pobrać listę produktów (id, name), kategorie (name), oraz powiązane przedmioty (id, name) wraz z przypisanymi im kategoriami (name).

{
  allProducts {
    id
    name
    categories {
	name
    }
    related {
      id
      name
      categories {
	  name
      }
    }
  }
}

Jeśli potrzebowalibyśmy dodatkowych zagnieżdżeń, możemy je po prostu dopisać:

[...]
    related {
      id
      name
      categories {
	  name
      }
      related {
        id
        name
        categories {
	    name
        }
      }
    }
[...]

Wysyłając nasze pierwsze query do serwera, możemy otrzymać przykładowe dane:

{
  "allProducts": [
    {
      "id": 153,
      "name": "kolczyki",
      "categories": [
        {
          "name": "Biżuteria"
        }
      ],
      "related": [
        {
          "id": 156,
          "name": "pierścionek złoty",
          "categories": [
            {
              "name": "Biżuteria"
            },
            {
              "name": "Złoto"
            }
          ]
        }
      ]
    },

  [...]
  ]
}

Jak widać, otrzymaliśmy dokładnie to, o co prosiliśmy.

Przedstawiony został tu uproszczony przykład tylko dla operacji Query, więcej przykładów można znaleźć na oficjalnej stronie https://graphql.org/learn/.

Autorem tekstu jest Maksym Kuras.

SOAP vs REST

Wymiana danych i integracja z zewnętrznymi systemami jest nieodłącznym elementem wszystkich złożonych aplikacji. Aby była możliwa, konieczne jest określenie konkretnych reguł i formatów komunikacji. Te zasady mogą określać protokoły komunikacji, czy też usystematyzowane struktury danych, artykuł skupi się na dwóch z nich: SOAP oraz REST.

SOAP (Simple Object Access Protocol) – protokół stworzony głównie na potrzeby Microsoftu w 1998 roku, w związku z zapotrzebowaniem na umożliwienie komunikacji pomiędzy aplikacjami z użyciem języka XML. Nadal szeroko używany, głównie ze względu na standaryzację, bezpieczeństwo i prostą kontrolę nad zawartością przekazanych danych.

REST (Representational State Transfer) – styl architektoniczny definiujący format przesyłanych danych, utworzony w 2000 roku przez Roya Fieldinga w ramach rozprawy doktorskiej, jako element standaryzacji protokołu HTTP. Używany ze względu na elastyczność, szybkość i prostotę. Nie jest protokołem – jako usługę RESTową można zdefiniować cache’owany, bezstanowy, komunikujący się na zasadzie klient-serwer serwis.

Format

Mnogość dostępnych formatów danych zdecydowanie przemawia na korzyść REST. Poza wiodącym JSONem, dane można wymieniać m. in. w formatach HTML, XML, YAML, czy nawet jako zwykły tekst. SOAP natomiast umożliwia komunikację jedynie z użyciem XML. Ograniczeniem RESTa jest natomiast jeden protokół – HTTP. SOAP możliwy jest dla ich szerszej gamy – m. in. HTTP, SMTP, czy UDP.

Bezpieczeństwo

SOAP wykorzystywany jest często ze względu na znaczące ułatwienia dotyczące bezpieczeństwa. Zaletami będą tutaj wsparcie dla WS-Security (rozszerzenie o elementy bezpieczeństwa, zapewniający integralność, poufność czy dołączanie tokenów do komunikatów), wbudowana logika wspomagająca komunikowanie błędów w integracji, czy łatwiejszą komunikację poprzez firewall oraz proxy. Jeśli chodzi o REST, wdrożenie analogicznych rozwiązań może być mniej wygodne. Oba rozwiązania oczywiście wspierają SSL.

Rozmiar danych

Wymuszenie przez SOAP formatu XML oraz określonych definicji w dokumencie powoduje narzut na przesyłane zapytanie. Dostępne dla REST formaty, takie jak JSON, czy YAML, mimo że mniej ustandaryzowane, jeśli chodzi o rozmiar są zdecydowanie bardziej optymalne. Różnica w rozmiarze (XML vs JSON) dla testowanych danych [6)] wyniosła około 25%.

Wydajność

REST trzeba uznać za zdecydowanie wydajniejszy. W związku z mniejszym rozmiarem wymaga mniejszej przepustowości łącza. Dla tej samej ilości danych potrzebuje również mniejszej mocy obliczeniowej. Aspekty te powodują szybsze działanie RESTa, nawet o kilkadziesiąt procent. REST również, w przeciwieństwie do SOAPa umożliwia cache’owanie wywołań API.

Zastosowanie

Funkcjonalnie patrząc, praktycznie każdą usługę sieciową można oprzeć zarówno na SOAP, jak i na REST. Z uwagi na wydajność i wygodę, obecnie zdecydowanie częściej korzysta się z RESTful API. Część istniejących już webserwisów opartych na SOAP, jest przepisywana na REST, pomimo próby zachowania obecnej funkcjonalności. Zastosowanie SOAPa jest bardziej wyspecjalizowane i może mieć on przewagę dla aplikacji, w których kluczowe jest bezpieczeństwo, jak np. różne usługi finansowe, bramki płatności.

Stanowość

Jednym z założeń RESTa jest komunikacja bezstanowa, co skutkuje brakiem tworzenia czy przechowywania sesji po stronie serwera, co wpływa korzystnie na łatwość powiększania systemu, czy jego modernizację. SOAP może działać zarówno bezstanowo, jak i z wykorzystaniem sesji.

Dane

REST traktuje dane jako zasoby; udostępnione one są za pomocą standardu URI (Uniform Resource Identifier), konkretne zasoby bywają w praktyce opisane w dokumentacji serwisu. SOAP udostępnia elementy logiki aplikacji jako usługi, definiowane według standardu WSDL opracowanego przez Microsoft i IBM. Plik definiuje, jakie informacje i w jaki sposób można wydobyć z serwisu.

Podsumowanie

Podsumowując, pomimo słabnącej popularności usług opartych na protokole SOAP i wielu zalet RESTa, nie jest możliwe jednoznaczne wybranie uniwersalnego lepszego rozwiązania. Dobór trzeba rozważyć zależnie od wdrażanej aplikacji – i mimo że w większości sytuacji najprawdopodobniej będzie to REST, SOAP nadal może okazać się przydatny.

Autorami tekstu są Łukasz Kowol i Jakub Sładek.

Źródła:
1) https://www.pearsonhighered.com/assets/samplechapter/0/6/7/2/0672326418.pdf
2) https://raygun.com/blog/soap-vs-rest-vs-json/
3) https://en.wikipedia.org/wiki/Representational_state_transfer
4) https://stackify.com/soap-vs-rest/
5) http://edu.pjwstk.edu.pl/wyklady/tbo/scb/lecture-13/lecture-13-content.html
6) https://aaltodoc.aalto.fi/bitstream/handle/123456789/29224/master_Makkonen_Joni_2017.pdf?sequence=1&isAllowed=y
7) https://www.guru99.com/comparison-between-web-services.html