Jak to się ma do siebie - REST API a SOAP, oraz wymiana danych.

Witam, tak się zastanawiałem generalnie jak się rozwija spore aplikacje internetowe, które np później chciałbym połączyć z innymi aplikacjami. Np. tworzenie sklepu internetowego naspianego w jednym z języków interpretrowanych (PHP, Ruby, Python, etc.) który później miałby by być połączony z jakimś programem do księgowania napisanym np. w .Net, czy Obj. C. Chodzi mi o to jak się realizuje komunikację danych w takim wypadku. Przychodzą mi do głowy następujące pomysły: 1) "Handlowanie" danymi poprzez bazę - np. MySQL może obsługiwać niemal każdy język, wiec jak coś zapiszę w aplikacji www, to odczytam z aplikacji .Net (Średnie to rozwiązanie, tak mi się przynajmniej wydaje) 2) Stworzenie API które pozwala pobierać dane bezpośrednio z aplikacji WWW. Tzn. napisanie RESTa na XMLu czy JSON`ie

Następnie zacząłem sobie troszeczkę szukać i dodatkowo przypomniało mi sie że jest coś takiego jak SOAP. I... się pogubiłem - czytając wiki dowiaduję się, żę REST API to sposób wymiany danych z użyciem XML itp. (a sam wiem, że zwykle robi się to za pomocą protokołu HTTP). Nie mniej jednak czytając opis SOAP widzę że to portokół wymiany danych w formacie XML poprzez HTTP, czy RPC. Co dziwne w przypisie nie ma odnisień wzajemnych do tych technologii.

Zatem moje pytanie brzmi: Czy jestem w błędzie, myśląc, że REST API to niemal to samo co SOAP ? Czy widzicie inną logiczną metodę wymiany danych?
Jak się ma do tego XML-RPC ?

  • REST opiera się na HTTP (tylko na nim działa!) i żeby z niego skorzystać trzeba od autora wysępić dokładną dokumentację. Do kodowania wiadomości moze być użyty JSON, XML, cokolwiek-innego. REST jest bardzo prosty w użyciu i nie wymaga skomplikowanych bibliotek.

    XML-RPC jest oparty w całości na XML i może działać z dowolnym protokołem transportowym (nie tylko HTTP). Moim zdaniem przesyła bardzo duzo nadmiarowych danych, ale za to sposób kodowania jest określony i ciężko wymyślić cos własnego w tej materii

    SOAP to protokół wymiany komunikatów. Wiadomości są zapisywane w XMLu, a przesylane czymkolwiek (HTTP,TCP, Named pipes, SMTP, MSMQ, itp.) Istnieje ustandaryzowany sposób publikowania informacji o usłudze (czym jest, jak z niej korzystać). Oprócz tego opracowano wiele rozszerzeń, które pozwalają na np. przetwarzanie transakcyjne, Claim-based security. Dodatkowo świetnie się sprawdza w językach ściśle typowanych (np. C#, Java).

  • Na dzień dzisiejszy najlepszym wyjściem jest REST. SOAP i XML-RPC służą generalnie do tego samego ale obie sa starszymi technologiami i czasem niepotrzebnie przekombinowanymi. REST z kolei jest przejrzysty i dla maszyny i człowieka, dzięki czemu jest bardziej niezawodny. Wg mnie REST do pary z JSON to idealny zestaw na wszelkiej maści wymianę danych poprzez HTTP. Poza tym REST/JSON to najmniejszy narzut na wielkość transferu danych, przy zachowaniu rozsądnego porządku.

  • Oba protokoły REST i SOAP mogą przesyłać dokumenty XML. Różnica polega na tym, że w SOAP dokładnie definiujesz co chcesz zrobić z czym. Musisz przygotować poprawny dokument XML z odpowiednimi sekcjami i opartym na przygotowanej do tego celu Schema'ie

    W REST natomiast CO CHCESZ ZROBIĆ definiujesz metodą wysyłki HTTP a w dokumencie definiujesz tylko Z CZYM TO MA BYĆ ZROBIONE. I tak np. Wysyłając ID produktu metodą GET otrzymasz informacje o tym produkcie, natomiast wysyłając ten sam ID metodą DELETE - usuniesz ten produkt.

    SOAP jest starszy, REST jest świeży, a co wybrać? IMO do lekkich usług warto zainteresować się się RESTEM(na którego właściwie jest moda dzisiaj - wszystko musi być restowe aby było fajne), jednak do aplikacji enterprise'owych wybrałbym SOAP, bo komunikację możesz oprzeć o sposób transakcyjny a nie tylko na zasadzie: pytanie-odpowiedź jak to się ma w przypadku RESTA.

    Z resztą warto trochę poszperać i zobaczyć jakie serwisy z czego korzystają: twitter, blip, - REST Amazon, Google Adsense, PayPal - SOAP

Zaloguj się, aby dodać swoją odpowiedź