Soap vs Rest

1. Wstęp

Od prostych aplikacji mobilnych po zaawansowane platformy korporacyjne, wymiana informacji pomiędzy różnymi programami stała się nieodłącznym elementem codziennego działania. Komunikacja między aplikacjami umożliwia integrację, współpracę oraz efektywne wykorzystanie zasobów, co przyczynia się do zwiększenia elastyczności i efektywności systemów informatycznych.

Istnieje szereg różnych protokołów, standardów i technologii, które umożliwiają komunikację między aplikacjami.

2. Protokół HTTP

Protokół HTTP jest często używany w połączeniu z protokołem TCP/IP (Transmission Control Protocol/Internet Protocol), który działa na warstwie transportowej. Jego działanie opiera się na kilku krokach:

1) Rozpoczęcie sesji – Klient inicjuje połączenie z serwerem, co może odbyć się poprzez otwarcie nowego gniazda (socket). Klient i serwer identyfikują się nawzajem, najczęściej za pomocą adresów IP i portów.

2) Handshake TCP (opcjonalny) – Jeśli protokół TCP jest używany (co jest standardowe w przypadku HTTP), może nastąpić proces ustanawiania połączenia zwany „three-way handshake”. Jest to seria komunikatów pomiędzy klientem a serwerem w celu ustalenia parametrów połączenia.

3) Wysyłanie żądania (Request) – Klient wysyła żądanie do serwera. Struktura żądania obejmuje:

• Linia rozpoczynająca (Request Line): Zawiera metodę (GET, POST, itp.), ścieżkę do zasobu oraz wersję protokołu HTTP.
• Nagłówki (Headers): Przesyłane informacje, takie jak User-Agent, Host, Content-Type itp.
• Pusta linia: Oddziela nagłówki od ewentualnych danych w ciele żądania.
• Ciało (Body): Opcjonalne dane, często używane w przypadku metod takich jak POST.

4) Przetwarzanie na serwerze – Serwer odbiera żądanie, analizuje je i decyduje, jak na nie odpowiedzieć. To może obejmować dostarczenie żądanych zasobów, przetworzenie danych, zapisanie informacji itp.

5) Wysyłanie odpowiedzi (Response) – Serwer generuje odpowiedź, która zawiera:

• Linia statusu (Status Line): Zawiera kod statusu (np. 200 OK) oraz wersję protokołu HTTP.
• Nagłówki (Headers): Przesyłane informacje, takie jak Content-Type, Content-Length itp.
• Pusta linia: Oddziela nagłówki od ciała odpowiedzi.
• Ciało (Body): Opcjonalne dane, takie jak treść strony.

6) Zakończenie sesji – Po zakończeniu wymiany danych sesja może być zamknięta, zwolnienie zasobów i zamknięcie gniazda, chyba że stosowana jest technika utrzymania połączenia keep-alive, pozwalająca na ponowne wykorzystanie połączenia do przyszłych żądań.

Warto zaznaczyć, że protokół HTTP jest bezstanowy, co oznacza, że każde żądanie jest obsługiwane niezależnie od poprzednich. Sprawia to, że każde żądanie i odpowiedź są izolowane, co ułatwia skalowanie oraz zapewnia elastyczność w obszarze komunikacji między klientem a serwerem.

3. SOAP

Komunikacja SOAP (Simple Object Access Protocol) odnosi się do procesu wymiany strukturalnych danych pomiędzy systemami przy użyciu protokołu SOAP. SOAP jest protokołem komunikacyjnym opartym na XML, a jego głównym celem jest umożliwienie komunikacji między różnymi systemami i aplikacjami, niezależnie od platformy czy języka programowania.

3.1. Struktura XML

W ramach komunikatu SOAP, dane są zazwyczaj zorganizowane w format XML, co ułatwia ich przetwarzanie i interpretację. Komunikat SOAP wygląda następująco:

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <soap:Header>
    <!-- Dodatkowe informacje kontrolne -->
    </soap:Header>
    <soap:Body>
    <!-- Dane przetwarzane przez komunikat -->
    </soap:Body>
</soap:Envelope>

a) Envelope (Koperta) –
Wszystkie elementy komunikatu SOAP są opakowane w tzw. „envelope” (kopertę). Jest to główny element, który otacza całą treść komunikatu.

b) Header (Nagłówek) – Element jest opcjonalny i zawiera dodatkowe informacje kontrolne, które mogą być używane przez aplikacje klienckie i serwerowe.

c) Body (Ciało) –
Element zawiera właściwe dane przetwarzane przez komunikat. To w tym elemencie umieszczone są operacje (metody) wykonywane na zdalnym serwerze.

3.2 Protokół komunikacyjny

Typowym nośnikiem dla komunikacji SOAP jest protokół HTTP, chociaż SOAP może być stosowany także z użyciem innych protokołów transportowych, takich jak SMTP czy MQ (Message Queues).

3.3 Metody (operacje)

Komunikacja SOAP obejmuje różne metody (operacje), które określają konkretne działania, jakie mają być wykonane na serwerze. Te metody są zdefiniowane w tzw. usługach webowych (web services)

WSDL

Plik WSDL (Web Services Description Language) to dokument XML służący do opisu interfejsu usługi internetowej (web service). WSDL definiuje, jakie operacje (metody) są dostępne w usłudze, jakie parametry i typy danych są używane, jakie są punkty końcowe (endpoints) usługi, oraz jakie protokoły komunikacyjne są obsługiwane.
Oto główne elementy, które można znaleźć w pliku WSDL:

1) Definitions (Definicje):
Początek pliku WSDL zawiera element , który jest kontenerem dla wszystkich definicji związanych z usługą.

2) Types (Typy):
Element może zawierać definicje typów danych używanych w operacjach usługi. WSDL obsługuje różne typy danych, takie jak proste typy (int, string) i bardziej skomplikowane typy złożone (np. struktury danych).

3) Message (Komunikat):
Element definiuje strukturę komunikatu przesyłanego między klientem a serwerem. Każdy komunikat składa się z jednego lub więcej elementów.

4) PortType (Typ Portu):
Element definiuje operacje dostępne w usłudze oraz strukturę komunikatów przesyłanych w trakcie tych operacji.

5) Binding (Wiązanie):
Element łączy abstrakcyjny portType z konkretnymi detalami implementacyjnymi, takimi jak protokół komunikacyjny i format komunikatu (np. SOAP).

6) Service (Usługa):
Element definiuje konkretny punkt dostępowy do usługi, zawierający jedno lub więcej portów.

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="HelloWorldService"
targetNamespace="http://example.com/HelloWorldService">

    <message name="SayHelloRequest">
        <part name="name" type="xsd:string"/>
    </message>

    <message name="SayHelloResponse">
        <part name="greeting" type="xsd:string"/>
    </message>

    <portType name="HelloWorldPortType">
        <operation name="SayHello">
            <input message="tns:SayHelloRequest"/>
            <output message="tns:SayHelloResponse"/>
        </operation>
    </portType>

    <binding name="HelloWorldSoapBinding" type="tns:HelloWorldPortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="SayHello">
            <soap:operation soapAction="http://example.com/HelloWorldService/SayHello"/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>

    <service name="HelloWorldService">
        <port name="HelloWorldPort" binding="tns:HelloWorldSoapBinding">
            <soap:address location="http://example.com/HelloWorldService"/>
        </port>
    </service>
</definitions>

Powyższy przykład ilustruje:

• Zdefiniowano tylko jedną operację o nazwie SayHello.
• Wiadomości SayHelloRequest i SayHelloResponse są proste i zawierają pojedyncze pola.
• Usługa działa w przestrzeni nazw http://example.com/HelloWorldService.

Plik WSDL jest kluczowy dla usług internetowych, ponieważ dostarcza klientom informacji na temat dostępnych operacji, sposobu ich wywoływania, a także formatu danych używanego w komunikacji. Dzięki temu, klienty mogą dynamicznie generować kod do komunikacji z usługą, co ułatwia integrację między różnymi systemami. Z drugiej strony plik WSDL może zostać wygenerowany na podstawie już istniejącej implementacji.

SOAP czy REST

SOAP

Definicja – Protokół komunikacyjny oparty na XML do wymiany struktur danych
Format danych – Zazwyczaj używa XML
Protokół transportowy – Może korzystać z różnych protokołów (np. HTTP, SMTP, JMS)
Stateful/Stateless – Może być zarówno stateful (stanowy) jak i stateless (bezstanowy)
Idempotencja – Zazwyczaj nie jest idempotentny
Interfejs – Duży nacisk na formalne operacje, korzysta z WSDL
Transakcje – Obsługuje transakcje poprzez standardy ACID
Bezpieczeństwo – Obszerne możliwości związane z bezpieczeństwem, takie jak WS-Security
Przeglądarki – Mniej przyjazny dla przeglądarek, trudniejsza implementacja w kliencie internetowym
Przykłady użycia – Często stosowany w rozbudowanych systemach korporacyjnych, zorientowanych na usługi
Wydajność – Zazwyczaj wymaga większej ilości zasobów i przepustowości

REST

Definicja – Styl architektoniczny bazujący na zasobach i operacjach na nich
Format danych – Zazwyczaj używa formatów bardziej lekkich, takich jak JSON, XML, lub HTML
Protokół transportowy – Zazwyczaj wykorzystuje protokół HTTP
Stateful/Stateless – Bezstanowy (stateless)
Idempotencja – Zazwyczaj jest idempotentny
Interfejs – Zorientowany na zasoby, prosty interfejs HTTP
Transakcje – Zazwyczaj korzysta z transakcji bazujących na zasobach
Bezpieczeństwo – Zazwyczaj korzysta z protokołu HTTPS i tokenów bezpieczeństwa
Przeglądarki – Bardziej przyjazny dla przeglądarek, łatwiejsza implementacja
Przykłady użycia – Popularny w aplikacjach internetowych, API, mikrousługach
Wydajność – Zazwyczaj jest bardziej wydajny i lekki, co może być korzystne w warunkach ograniczonych zasobów

Podsumowanie

Warto zauważyć, że wybór między SOAP a REST zależy od konkretnych potrzeb projektu, a obie technologie mają swoje miejsce w różnych kontekstach w zależności od specyfiki projektu i wymagań funkcjonalnych.