Czy ktoś może wyjaśnić, czym jest REST, a co SOAP zwykłym angielskim? A jak działają usługi sieciowe?

Proste wyjaśnienie dotyczące SOAP i REST

SOAP - „Simple Object Access Protocol”

SOAP to metoda przesyłania wiadomości lub niewielkich ilości informacji przez Internet. Wiadomości SOAP są formatowane w formacie XML i zwykle są wysyłane przy użyciu protokołu HTTP (protokół przesyłania hipertekstu).

Reszta - reprezentatywny transfer stanu

Reszta to prosty sposób wysyłania i odbierania danych między klientem a serwerem i nie ma zbyt wielu zdefiniowanych standardów. Możesz wysyłać i odbierać dane w formacie JSON, XML lub nawet jako zwykły tekst. Jest lekki w porównaniu do SOAP.

Obie metody są używane przez wielu dużych graczy. To kwestia preferencji. Preferuję REST, ponieważ jest łatwiejszy w użyciu i zrozumieniu.

Simple Object Access Protocol (SOAP):

• SOAP buduje protokół XML na bazie HTTP lub czasami TCP / IP.
• SOAP opisuje funkcje i typy danych.
• SOAP jest następcą XML-RPC i jest bardzo podobny, ale opisuje standardowy sposób komunikacji.
• Kilka języków programowania ma natywną obsługę protokołu SOAP, zwykle podajesz mu adres URL usługi sieci Web i możesz wywoływać jej funkcje bez potrzeby podawania specjalnego kodu.
• Wysyłane dane binarne muszą być najpierw zakodowane w formacie takim jak kodowanie base64.
• Ma kilka protokołów i technologii z tym związanych: WSDL, XSD, SOAP, WS-Addressing

Reprezentatywny transfer stanu (REST):

• REST nie musi być przez HTTP, ale większość moich punktów poniżej będzie miała stronniczość HTTP.
• REST jest bardzo lekki, mówi: poczekaj chwilę, nie potrzebujemy całej tej złożoności, którą stworzył SOAP.
• Zwykle używa normalnych metod HTTP zamiast dużego formatu XML opisującego wszystko. Na przykład, aby uzyskać zasób, którego używasz HTTP GET, aby umieścić zasób na serwerze, którego używasz HTTP PUT. Aby usunąć zasób na serwerze, użyj HTTP DELETE.
• REST jest bardzo prosty, ponieważ używa metod HTTP GET, POST i PUT do aktualizacji zasobów na serwerze.
• REST zazwyczaj najlepiej jest stosować z architekturą zorientowaną na zasoby (ROA). W tym sposobie myślenia wszystko jest zasobem i działałbyś na tych zasobach.
• Tak długo, jak twój język programowania ma bibliotekę HTTP, a większość tak, możesz bardzo łatwo korzystać z protokołu HTTP REST.
• Dane binarne lub zasoby binarne można po prostu dostarczyć na ich żądanie.

Nie ma końca debat na temat REST vs SOAP w Google .

Moim ulubionym jest ten . Aktualizacja 27 listopada 2013: Wygląda na to, że strona Paula Prescoda przeszła w tryb offline, a ten artykuł nie jest już dostępny, chociaż kopie można znaleźć na Wayback Machine lub jako plik PDF na CiteSeerX .

RESZTA

Rozumiem, że główna idea REST jest niezwykle prosta. Od lat korzystamy z przeglądarek internetowych i przekonaliśmy się, jak łatwe, elastyczne, skuteczne itp. Są strony internetowe. Witryny HTML używają hiperłączy i formularzy jako podstawowego sposobu interakcji użytkownika. Ich głównym celem jest umożliwienie nam, klientom, poznania tylko tych linków, których możemy używać w obecnym stanie . A REST po prostu mówi „dlaczego nie zastosować tych samych zasad do kierowania komputerem, a nie ludzkimi klientami za pośrednictwem naszej aplikacji?” Połącz to z mocą infrastruktury WWW, a otrzymasz narzędzie do tworzenia świetnych aplikacji rozproszonych.

Innym możliwym wytłumaczeniem są ludzie matematycznie myślący. Każda aplikacja jest w zasadzie maszyną stanową, a operacje logiczne są przejściami stanu. Ideą REST jest mapowanie każdego przejścia na jakieś żądanie do zasobu i zapewnienie klientom łączy reprezentujących przejścia dostępne w bieżącym stanie. W ten sposób modeluje maszynę stanową za pomocą reprezentacji i łączy. Dlatego nazywa się to REpresentational State Transfer.

To dość zaskakujące, że wszystkie odpowiedzi wydają się koncentrować albo na formacie wiadomości, albo na użyciu czasowników HTTP. W rzeczywistości format komunikatu nie ma żadnego znaczenia, REST może użyć dowolnego, pod warunkiem, że programista go udokumentuje. Czasowniki HTTP sprawiają, że usługa jest usługą CRUD, ale jeszcze nie jest RESTful. To, co naprawdę zmienia usługę w usługę REST, to hiperłącza (inaczej formanty hipermedia) osadzone w odpowiedziach serwera wraz z danymi, a ich ilość musi być wystarczająca, aby każdy klient mógł wybrać następne działanie z tych łączy.

Niestety, raczej trudno jest znaleźć prawidłowe informacje na temat REST w Internecie, z wyjątkiem tezy Roya Fieldinga . (To on opracował REST). Polecam „Rest in Practice” książki , ponieważ daje kompleksowy poradnik krok po kroku, w jaki sposób ewoluują od mydła na odpoczynek.

MYDŁO

Jest to jedna z możliwych form stylu architektury RPC (Remote Procedural Call). Zasadniczo jest to tylko technologia, która pozwala klientom wywoływać metody serwera przez granice usług (sieć, procesy itp.) Tak, jakby wywoływali metody lokalne. Oczywiście tak naprawdę różni się od wywoływania metod lokalnych szybkością, niezawodnością i tak dalej, ale pomysł jest taki prosty.

W porównaniu

Szczegóły, takie jak protokoły transportu, formaty komunikatów, xsd, wsdl itp. Nie mają znaczenia przy porównywaniu dowolnej formy RPC z REST. Główną różnicą jest to, że usługa RPC zmienia styl roweru, projektując własny protokół aplikacji w interfejsie RPC API z semantyką, którą zna tylko on. Dlatego wszyscy klienci muszą zrozumieć ten protokół przed skorzystaniem z usługi i nie można zbudować ogólnej infrastruktury, takiej jak pamięci podręczne, z powodu zastrzeżonej semantyki wszystkich żądań. Ponadto interfejsy API RPC nie sugerują, jakie działania są dozwolone w bieżącym stanie, należy to wywnioskować z dodatkowej dokumentacji. Z drugiej strony REST wymaga użycia jednolitych interfejsów, aby umożliwić różnym klientom zrozumienie semantyki API oraz kontroli hipermedialnych (linków) w celu wyróżnienia dostępnych opcji w każdym stanie. A zatem,

W pewnym sensie SOAP (jak każde inne RPC) jest próbą tunelowania przez granicę usługi, traktując łączące się media jako czarną skrzynkę zdolną do przesyłania tylko komunikatów. REST jest decyzją o uznaniu, że sieć jest ogromnym, rozproszonym systemem informacyjnym, aby zaakceptować świat takim, jaki jest, i nauczyć się go opanowywać zamiast z nim walczyć.

SOAP wydaje się być świetny do wewnętrznych interfejsów API sieci, gdy kontrolujesz zarówno serwer, jak i klientów, a interakcje nie są zbyt skomplikowane. Używanie go przez programistów jest bardziej naturalne. Jednak w przypadku publicznego interfejsu API, który jest używany przez wiele niezależnych podmiotów, jest złożony i duży, REST powinien pasować lepiej. Ale to ostatnie porównanie jest bardzo rozmyte.

Aktualizacja

Moje doświadczenie nieoczekiwanie pokazało, że rozwój REST jest trudniejszy niż SOAP. Przynajmniej dla .NET. Chociaż istnieją świetne frameworki, takie jak ASP.NET Web API, nie ma narzędzi, które automatycznie generowałyby proxy po stronie klienta. Nie ma to jak „Dodaj odniesienie do usługi sieci Web” lub „Dodaj odniesienie do usługi WCF”. Należy ręcznie napisać cały kod serializacji i zapytania o usługę. I stary, to dużo kodu z podstawowymi danymi. Myślę, że rozwój REST potrzebuje czegoś podobnego do WSDL i implementacji narzędzi dla każdej platformy programistycznej. W rzeczywistości wydaje się, że istnieje dobry grunt: WADL lub WSDL 2.0 , ale żaden ze standardów nie wydaje się być dobrze obsługiwany.

Aktualizacja (styczeń 2016 r.)

Okazuje się, że istnieje szeroka gama narzędzi do definiowania interfejsu API REST. Moje osobiste preferencje to obecnie RAML .

Jak działają usługi sieciowe?

To zbyt szerokie pytanie, ponieważ zależy od architektury i technologii zastosowanej w konkretnej usłudze internetowej. Ale ogólnie rzecz biorąc, usługa internetowa to po prostu aplikacja w sieci, która może przyjmować żądania od klientów i zwracać odpowiedzi. Jest narażony na działanie Internetu, dlatego jest usługą internetową i zazwyczaj jest dostępny 24 godziny na dobę, 7 dni w tygodniu, dlatego jest to usługa . Oczywiście rozwiązuje to pewien problem (inaczej dlaczego ktoś miałby kiedykolwiek korzystać z usługi internetowej) dla swoich klientów.

To najprostsze wyjaśnienie, jakie kiedykolwiek znajdziesz.

Ten artykuł zabiera narrację męża do żony, w której mąż wyjaśnia swojej żonie o REST, czysto laik. Musisz przeczytać!

How-i-wyjaśnił-rest-to-my-wife (oryginalny link)
How-i-wyjaśnił-rest-to-my-wife (link roboczy 2013-07-19)

SOAP - Simple Object Access Protocol to protokół !

REST - REpresentational State Transfer to styl architektoniczny !

SOAP jest protokołem XML używanym do przesyłania wiadomości, zwykle przez HTTP

RESTi SOAPto zapewne nie wykluczają się wzajemnie. Architektura RESTful może użyć HTTPlub SOAPinnego protokołu komunikacyjnego. RESTjest zoptymalizowany pod kątem internetu i dlatego HTTPjest idealnym wyborem. HTTPjest także jedynym protokołem omawianym w pracy Roya Fieldinga.

Chociaż REST i SOAP są wyraźnie bardzo różne, pytanie to wyjaśnia fakt, że RESTi HTTPczęsto są używane w tandemie. Wynika to przede wszystkim z prostoty HTTP i jej bardzo naturalnego mapowania na zasady RESTful.

Podstawowe zasady REST

Komunikacja klient-serwer

Architektura klient-serwer ma bardzo wyraźny podział problemów. Wszystkie aplikacje zbudowane w stylu RESTful muszą również być w zasadzie klient-serwer.

Bezpaństwowiec

Każde żądanie klienta skierowane do serwera wymaga pełnego przedstawienia jego stanu. Serwer musi być w stanie w pełni zrozumieć żądanie klienta bez użycia kontekstu serwera lub stanu sesji serwera. Wynika z tego, że cały stan musi być zachowany na kliencie. Bardziej szczegółowo omówimy reprezentację bezstanową.

Pamięć podręczna

Można zastosować ograniczenia pamięci podręcznej, umożliwiając w ten sposób oznaczenie danych odpowiedzi jako buforowalnych lub niemożliwych do buforowania. Wszelkie dane oznaczone jako buforowalne mogą być ponownie wykorzystane jako odpowiedź na to samo kolejne żądanie.

Jednolity interfejs

Wszystkie komponenty muszą współdziałać poprzez jeden jednolity interfejs. Ponieważ interakcja wszystkich komponentów odbywa się za pośrednictwem tego interfejsu, interakcja z różnymi usługami jest bardzo prosta. Interfejs jest taki sam! Oznacza to również, że zmiany implementacji można wprowadzać oddzielnie. Takie zmiany nie wpłyną na podstawowe interakcje komponentów, ponieważ jednolity interfejs jest zawsze niezmieniony. Jedną wadą jest to, że utknąłeś z interfejsem. Jeśli można zoptymalizować konkretną usługę poprzez zmianę interfejsu, nie masz szczęścia, ponieważ REST tego zabrania. Z drugiej strony REST jest zoptymalizowany dla Internetu, stąd niesamowita popularność REST przez HTTP!

Powyższe koncepcje reprezentują definiowanie cech REST i odróżniają architekturę REST od innych architektur, takich jak usługi sieciowe. Warto zauważyć, że usługa REST jest usługą internetową, ale usługa internetowa niekoniecznie jest usługą REST.

Zobacz ten post na blogu na temat REST Design Principals, aby uzyskać więcej informacji na temat REST i wyżej wymienionych punktorów.

Podoba mi się odpowiedź Briana R. Bondy'ego. Chciałem tylko dodać, że Wikipedia zawiera jasny opis REST . Artykuł odróżnia go od SOAP.

REST to wymiana informacji o stanie, wykonywana tak prosto, jak to możliwe.

SOAP to protokół komunikatów korzystający z XML.

Jednym z głównych powodów, dla których wiele osób przeniosło się z SOAP do REST, jest to, że standardy WS- * (zwane WS splat) związane z usługami sieciowymi opartymi na SOAP są BARDZO skomplikowane. Zobacz wikipedia, aby uzyskać listę specyfikacji. Każda z tych specyfikacji jest bardzo skomplikowana.

EDYCJA: z jakiegoś powodu linki nie są wyświetlane poprawnie. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Zarówno usługi SOAP, jak i usługi REST mogą korzystać z protokołu HTTP i innych protokołów (żeby wspomnieć, że SOAP może być podstawowym protokołem REST). Będę mówić tylko o SOAP i REST związanych z protokołem HTTP, ponieważ jest to najczęściej ich użycie.

MYDŁO

SOAP („prosty” protokół dostępu do obiektu) to protokół (i standard W3C ). Określa sposób tworzenia, wysyłania i przetwarzania wiadomości SOAP.

• Wiadomości SOAP to dokumenty XML o określonej strukturze: zawierają kopertę zawierającą nagłówek i sekcję treści. Treść zawiera rzeczywiste dane - które chcemy wysłać - w formacie XML. Istnieją dwa style kodowania , ale zwykle wybieramy literał , co oznacza, że ​​nasza aplikacja lub sterownik SOAP wykonuje serializację XML i rozproszenie danych.

• Wiadomości SOAP są przesyłane jako wiadomości HTTP z podtypem SOAP + XML MIME. Te wiadomości HTTP mogą być wieloczęściowe, więc opcjonalnie możemy dołączyć pliki do wiadomości SOAP.

• Oczywiście używamy architektury klient-serwer, więc klienci SOAP wysyłają żądania do serwisów WWW SOAP, a usługi wysyłają odpowiedzi do klientów. Większość usług internetowych używa pliku WSDL do opisania usługi. Plik WSDL zawiera schemat XML (dalej XSD) danych, które chcemy wysłać, oraz powiązanie WSDL, które definiuje sposób, w jaki usługa internetowa jest powiązana z protokołem HTTP. Istnieją dwa wiążące style: RPC i dokument. Poprzez powiązanie stylu RPC treść SOAP zawiera reprezentację wywołania operacji z parametrami (żądania HTTP) lub zwracanymi wartościami (odpowiedź HTTP). Parametry i zwracane wartości są sprawdzane względem XSD. Poprzez powiązanie stylu dokumentu treść SOAP zawiera dokument XML, który jest sprawdzany pod kątem XSD. Myślę, że styl wiązania dokumentu lepiej pasuje do systemów opartych na zdarzeniach, ale nigdy nie użyłem tego stylu wiązania. Styl wiązania RPC jest bardziej rozpowszechniony, więc większość ludzi używa SOAP do celów XML / RPC przez aplikacje rozproszone. Usługi sieciowe zwykle się odnajdują, pytając serwer UDDI . Serwery UDDI to rejestry przechowujące lokalizację usług internetowych.

SOAP RPC

Tak więc - moim zdaniem - najbardziej rozpowszechniona usługa SOAP używa stylu wiązania RPC i dosłownego stylu kodowania i ma następujące właściwości:

• Odwzorowuje adresy URL na operacje.
• Wysyła wiadomości z podtypem SOAP + XML MIME.
• Może mieć magazyn sesji po stronie serwera, nie ma na to żadnych ograniczeń.
• Sterowniki klienta SOAP używają pliku WSDL usługi do konwersji operacji RPC na metody. Aplikacja po stronie klienta komunikuje się z usługą SOAP, wywołując te metody. Dlatego większość klientów SOAP dzieli się według zmian interfejsu (wynikające nazwy metod i / lub zmiany parametrów).
• Możliwe jest pisanie klientów SOAP, które nie będą łamać się przez zmiany interfejsu za pomocą RDF i znajdować operacje według semantyki, ale semantyczna usługa internetowa jest bardzo rzadka i niekoniecznie ma klienta nie psującego się (tak sądzę).

RESZTA

REST (reprezentatywny transfer stanu) to styl architektury opisany w rozprawie Roy Fieldinga. Nie dotyczy protokołów jak SOAP. Zaczyna się od stylu zerowej architektury bez ograniczeń i definiuje ograniczenia architektury REST jeden po drugim. Ludzie używają terminu RESTful dla usług sieciowych, które spełniają wszystkie ograniczenia REST, ale zgodnie z Royem Fieldingiem nie ma takich rzeczy jak poziomy REST . Gdy usługa internetowa nie spełnia wszystkich ograniczeń REST, nie jest to usługa internetowa REST.

Ograniczenia REST

• Architektura klient - serwer - Myślę, że ta część jest znana wszystkim. Klienci REST komunikują się z usługami sieci Web REST, usługi te utrzymują wspólne dane - stan zasobów dalej - i serwują je klientom.
• Bezstanowy - część skrótu „transfer stanu”: REST. Klienci utrzymują stan klienta (stan sesji / aplikacji), więc usługi nie mogą mieć pamięci sesji. Klienci przesyłają odpowiednią część stanu klienta przez każde żądanie do usług, które odpowiadają odpowiednią częścią stanu zasobów (utrzymywanego przez nich). Więc żądania nie mają kontekstu, zawsze zawierają informacje niezbędne do ich przetworzenia. Na przykład przez podstawowe uwierzytelnianie HTTP nazwa użytkownika i hasło są przechowywane przez klienta i wysyła je przy każdym żądaniu, więc uwierzytelnianie odbywa się przy każdym żądaniu. To bardzo różni się od zwykłych aplikacji internetowych, w których uwierzytelnianie odbywa się tylko po zalogowaniu. Możemy użyć dowolnego mechanizmu przechowywania danych po stronie klienta, takiego jak in-memory (javascript), pliki cookie, localStorage i tak dalej ... aby zachować niektóre części stanu klienta, jeśli chcemy. Powodem ograniczenia bezpaństwowości jest to, że serwer dobrze się skaluje - nawet przy bardzo dużym obciążeniu (miliony użytkowników) - gdy nie musi utrzymywać sesji każdego klienta.
• Pamięć podręczna - odpowiedź musi zawierać informacje, które mogą być buforowane przez klienta lub nie. To jeszcze bardziej poprawia skalowalność.

• Jednolity interfejs

  • Identyfikacja zasobów - zasób REST jest taki sam jak zasób RDF . Według Fieldinga, jeśli możesz coś nazwać, może to być zasób, na przykład: „bieżąca lokalna pogoda” może być zasobem lub „twój telefon komórkowy” może być zasobem, lub „konkretny dokument internetowy” może być zasób. Aby zidentyfikować zasób, możesz użyć identyfikatorów zasobów: adresów URL i URN (na przykład numer ISBN według książek ). Pojedynczy identyfikator powinien należeć tylko do określonego zasobu, ale pojedynczy zasób może mieć wiele identyfikatorów, które często wykorzystujemy na przykład przez podział na strony z takimi adresami URL https://example.com/api/v1/users?offset=50&count=25. Adresy URL mają pewne specyfikacje, na przykład adresy URL z tymi samymi ścieżkami, ale różne zapytania nie są identyczne, lub część ścieżki powinna zawierać dane hierarhiczne adresu URL, a część zapytania powinna zawierać dane niehierarchiczne. Są to podstawy tworzenia adresów URL przez REST. Btw. struktura URL ma znaczenie tylko dla twórców usług, prawdziwy klient REST nie zajmuje się tym. Innym często zadawanym pytaniem jest wersja API, która jest łatwa, ponieważ według Fielding jedyną stałą rzeczą według zasobów jest semantyka. Jeśli semantyka ulegnie zmianie, możesz dodać nowy numer wersji. Możesz użyć klasycznej wersji 3-cyfrowej i dodać tylko główną liczbę do adresów URL (https://example.com/api/v1/). Tak więc przez zmiany kompatybilne wstecz nic się nie dzieje, przez zmiany niezgodne wstecz będziesz miał semantykę niezgodną wstecz z nowym katalogiem głównym API https://example.com/api/v2/. Tak więc starzy klienci się nie zepsują, ponieważ mogą używać https://example.com/api/v1/starej semantyki.
  • Manipulowanie zasobami za pomocą reprezentacji - można manipulować danymi związanymi z zasobami (stanem zasobu), wysyłając zamierzoną reprezentację zasobów - wraz z metodą HTTP i identyfikatorem zasobu - do usługi REST. Na przykład, jeśli chcesz zmienić nazwę użytkownika po ślubie, możesz wysłać PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}żądanie, w którym {name: "Mrs Smith"}jest reprezentacją JSON zamierzonego stanu zasobów, innymi słowy: nowa nazwa. Dzieje się tak na odwrót, usługa wysyła reprezentacje zasobów do klientów w celu zmiany ich stanów. Na przykład, jeśli chcemy odczytać nową nazwę, możemy wysłać GET https://example.com/api/v1/users/1?fields="name"prośbę o pobranie, co powoduje, że200 ok, {name: "Mrs Smith"}odpowiedź. Możemy więc użyć tej reprezentacji do zmiany stanu klienta, na przykład możemy wyświetlić „Witamy na naszej stronie, pani Smith!” wiadomość. Zasób może mieć wiele reprezentacji w zależności od identyfikatora zasobu (URL) lub acceptnagłówka, który wysłaliśmy z żądaniem. Na przykład możemy wysłać zdjęcie pani Smith (prawdopodobnie nie nagiej), jeśli image/jpegzostanie o to poproszone.
  • Wiadomości opisowe - wiadomości muszą zawierać informacje o tym, jak je przetwarzać. Na przykład metoda URI i HTTP, nagłówek typu zawartości, nagłówki pamięci podręcznej, RDF, który opisuje znaczenie danych itp. Ważne jest, aby używać standardowych metod. Ważne jest, aby znać specyfikację metod HTTP. Na przykład GET oznacza pobieranie informacji identyfikowanych przez adres URL żądania, DELETE oznacza proszenie serwera o usunięcie zasobu zidentyfikowanego przez podany adres URL itd. ... Kody stanu HTTP mają również specyfikację , na przykład 200 oznacza sukces, 201 oznacza nowy zasób został utworzony, 404 oznacza, że ​​żądanego zasobu nie znaleziono na serwerze itp. Korzystanie z istniejących standardów jest ważną częścią REST.

  • Hypermedia jako silnik stanu aplikacji (HATEOAS dalej) - Hypermedia to rodzaj mediów, który może zawierać hiperłącza. W Internecie podążamy za linkami - opisanymi w formacie hipermedialnym (zwykle HTML) - aby osiągnąć cel, zamiast wpisywać adresy URL w pasku adresu. Usługa REST działa zgodnie z tą samą koncepcją, reprezentacje wysyłane przez usługę mogą zawierać hiperłącza. Używamy tych hiperłączy do wysyłania żądań do usługi. Z odpowiedzią otrzymujemy dane (i prawdopodobnie więcej linków), których możemy użyć do zbudowania nowego stanu klienta i tak dalej ... Dlatego właśnie hipermedia jest silnikiem stanu aplikacji (stan klienta). Prawdopodobnie zastanawiasz się, jak klienci rozpoznają hiperłącza i podążają za nimi? Dla ludzi jest to dość proste, odczytujemy tytuł linku, może wypełniamy pola wejściowe, a potem tylko jedno kliknięcie.JSON-LD z Hydrą ) lub z rozwiązaniami specyficznymi dla hipermediów (na przykład relacje łącza IANA i typy MIME specyficzne dla dostawcy przez HAL + JSON ). Istnieje wiele formatów hipermedialnych XML i JSON do odczytu maszynowego , tylko krótka lista:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Syrena
    • Kolekcja + JSON

    Czasami trudno jest wybrać ...

• System warstwowy - Możemy używać wielu warstw między klientami a usługami. Żadna z nich nie powinna wiedzieć o wszystkich tych dodatkowych warstwach, tylko o warstwie tuż obok niej. Te warstwy mogą poprawić skalowalność poprzez zastosowanie pamięci podręcznej i równoważenia obciążenia lub mogą egzekwować zasady bezpieczeństwa.
• Kod na żądanie - możemy wysłać kod zwrotny, który rozszerza funkcjonalność klienta, na przykład kod javascript do przeglądarki. Jest to jedyne opcjonalne ograniczenie REST.

Usługa REST - różnice w usłudze RPAP RPC

Tak więc usługa REST bardzo różni się od usługi SOAP (ze stylem wiązania RPC i dosłownym stylem kodowania)

• Definiuje jednolity interfejs (intead of protokołu).
• Odwzorowuje adresy URL na zasoby (a nie operacje).
• Wysyła wiadomości o dowolnym typie MIME (zamiast po prostu SOAP + XML).
• Ma komunikację bezstanową, więc nie może mieć pamięci sesji po stronie serwera. (SOAP nie ma co do tego żadnych ograniczeń)
• Obsługuje hipermedia, a klienci używają linków zawartych w tej hipermedii do żądania usługi. (SOAP RPC używa powiązań operacji opisanych w pliku WSDL)
• Nie dzieli się według zmian adresu URL tylko zmianami semantyki. (Klienci SOAP RPC bez użycia semantyki RDF dzielą się na zmiany pliku WSDL).
• Skaluje się lepiej niż usługa SOAP ze względu na swoje bezpaństwowe zachowanie.

i tak dalej...

Usługa RPC SOAP RPC nie spełnia wszystkich ograniczeń REST:

• architektura klient-serwer - zawsze
• bezpaństwowy - możliwy
• pamięć podręczna - możliwe
• jednolity interfejs - nigdy
• system warstwowy - nigdy
• kod na żądanie (opcjonalnie) - możliwe

Zacznę od drugiego pytania: czym są usługi sieciowe? , z oczywistych powodów.

WebServices to w zasadzie elementy logiki (które można niejasno określić jako metodę), które ujawniają określone funkcje lub dane. Klient implementujący (technicznie rzecz biorąc, słowo konsumujące ) musi tylko wiedzieć, jakie są parametry, które metoda zamierza zaakceptować i jaki typ danych zwróci (jeśli w ogóle to zrobi).

Poniższy link mówi wszystko o REST i SOAP w niezwykle przejrzysty sposób.

REST vs SOAP

Jeśli chcesz również wiedzieć, kiedy wybrać, co (REST lub SOAP), tym więcej powodów, aby przejść przez to!

Zarówno SOAP, jak i REST odnoszą się do sposobów komunikowania się między różnymi systemami.

REST robi to przy użyciu technik, które przypominają komunikację twojej przeglądarki z serwerami WWW: używając GET do żądania strony internetowej, POST w polach formularza itp.

SOAP zapewnia coś podobnego, ale robi wszystko poprzez wysyłanie bloków XML tam iz powrotem. Innym kluczowym składnikiem SOAP jest WSDL, który jest dokumentem XML opisującym obsługiwane funkcje i elementy danych. WSDL można wykorzystać do programowego „odkrycia” obsługiwanych funkcji, a także do generowania kodów pośredniczących w programowaniu.

Myślę, że to tak proste, jak to potrafię wyjaśnić. Proszę, każdy może mnie poprawić lub dodać do tego.

SOAP jest formatem wiadomości używanym przez odłączone systemy (takie jak Internet) do wymiany informacji / danych. Dzieje się tak z komunikatami XML przewijanymi w przód i w tył.

Usługi sieciowe transmitują lub odbierają wiadomości SOAP. Działają inaczej w zależności od języka, w którym są napisane.

Problem z SOAP polega na tym, że jest on w konflikcie z ideałami stojącymi za stosem HTTP. Każde oprogramowanie pośrednie powinno być w stanie pracować z żądaniami HTTP bez zrozumienia treści żądania lub odpowiedzi, ale na przykład zwykły serwer buforujący HTTP nie będzie działał z żądaniami SOAP, nie wiedząc tylko, które części zawartości SOAP mają znaczenie dla buforowania. SOAP po prostu używa HTTP jako opakowania własnego protokołu komunikacyjnego, takiego jak serwer proxy.

REST to styl architektury do projektowania aplikacji sieciowych. Chodzi o to, że zamiast używać złożonych mechanizmów, takich jak CORBA, RPC lub SOAP, do łączenia się między komputerami, do nawiązywania połączeń między komputerami używa się prostego protokołu HTTP.

SOAP - „Simple Object Access Protocol”

SOAP to niewielkie przesłanie wiadomości lub niewielka ilość informacji przez Internet. Wiadomości SOAP są formatowane w formacie XML i zwykle są wysyłane przy użyciu protokołu HTTP .

REST - „Reprezentacyjny transfer stanu”

REST jest podstawowym procesem ewentualności i odbierania informacji między wentylatorem a serwerem i nie ma jednoznacznie wielu zdefiniowanych standardów. Możesz wysyłać i akceptować informacje jako JSON , XML lub nawet zwykły tekst. Jest lekki w porównaniu do SOAP .

Usługi sieciowe oparte na SOAP Krótko mówiąc, model usług opartych na SOAP postrzega świat jako ekosystem równych rówieśników, którzy nie mogą się nawzajem kontrolować, ale muszą współpracować, honorując opublikowane umowy. Jest to poprawny model bałaganu w prawdziwym świecie, a umowy oparte na metadanych tworzą interfejs usługi SOAP.

nadal możemy kojarzyć SOAP ze zdalnymi wywołaniami procedur opartymi na XML, ale technologia usług sieciowych SOAP stała się elastycznym i wydajnym modelem przesyłania komunikatów.

SOAP zakłada, że ​​wszystkie systemy są niezależne i żaden system nie ma wiedzy na temat wewnętrznych funkcji innej i wewnętrznej funkcjonalności. Większość takich systemów może wysyłać do siebie wiadomości i mieć nadzieję, że zostaną na nie zareagowane. Systemy publikują umowy, które zobowiązują się honorować, a inne systemy polegają na tych umowach w celu wymiany wiadomości z nimi.

Umowy między systemami są łącznie nazywane metadanymi i obejmują opisy usług, obsługiwane wzorce wymiany komunikatów oraz zasady regulujące jakość usługi (usługa może wymagać zaszyfrowania, niezawodnego dostarczenia itp.) Z kolei opis usługi jest szczegółowym specyfikacja danych (dokumenty wiadomości), które zostaną wysłane i odebrane przez system. Dokumenty są opisane przy użyciu języka opisu XML, takiego jak Definicja schematu XML. Tak długo, jak wszystkie systemy honorują opublikowane umowy, mogą ze sobą współpracować, a zmiany w wewnętrznych systemach nigdy nie wpływają na żadne inne. Każdy system jest odpowiedzialny za tłumaczenie własnych wewnętrznych wdrożeń na i z kontraktów

REST - REpresentational State Transfer. Fizycznym protokołem jest HTTP. Zasadniczo REST polega na tym, że wszystkie odrębne zasoby w sieci są jednoznacznie identyfikowalne za pomocą adresu URL. Wszystkie operacje, które można wykonać na tych zasobach, można opisać ograniczonym zestawem czasowników (czasowników „CRUD”), które z kolei odwzorowują czasowniki HTTP.

REST jest znacznie mniej „ciężki” niż SOAP.

Działanie serwisu internetowego