Mydło vs Reszta (różnice)

REST vs SOAP jest Nie właściwe pytanie.

REST, w przeciwieństwie do SOAP jest Nie protokół.

REST jest styl architektoniczny i projekt dla sieciowych architektur oprogramowania.

REST pojęcia określane są jako zasoby. Reprezentacja zasobu musi być bezpaństwowa. Jest reprezentowany przez jakiś typ nośnika. Niektóre przykłady typów mediów obejmują XML, JSON, i RDF. Zasoby są manipulowane przez komponenty. Komponenty żądają zasobów i manipulują nimi za pomocą standardowego jednolitego interfejsu. W przypadku HTTP interfejs ten składa się ze standardowego HTTP ops np. GET, PUT, POST, DELETE.

@ Abdulaziz pytanie nie wyjaśnia faktu, że REST i HTTP są często używane w tandemie. Wynika to przede wszystkim z prostoty HTTP i jego bardzo naturalnego mapowania do zasad RESTful.

Fundamentalny odpoczynek Zasady

Komunikacja Klient-Serwer

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

Stateless

Każde żądanie klienta do serwera wymaga, aby jego stan był w pełni reprezentowany. Serwer musi być w stanie w pełni zrozumieć żądanie klienta bez użycia kontekstu serwera lub stanu sesji serwera. Informatyka wynika z tego, że cały stan musi być utrzymywany na kliencie.

Cacheable

Mogą być stosowane ograniczenia pamięci podręcznej, dzięki czemu DANE odpowiedzi mogą być oznaczone jako buforowalne lub nie-buforowalne. Wszelkie dane oznaczone jako buforowalne mogą być ponownie wykorzystane jako odpowiedź na to samo kolejne żądanie.

Jednolity Interfejs

Wszystkie komponenty muszą współdziałać przez jeden jednolity interfejs. Ponieważ cała interakcja komponentu zachodzi za pośrednictwem tego interfejsu, interakcja z różne usługi są bardzo proste. Interfejs jest taki sam! Oznacza to również, że zmiany we wdrażaniu mogą być dokonywane w izolacji. Takie zmiany nie będą miały wpływu na podstawową interakcję komponentów, ponieważ jednolity interfejs jest zawsze niezmieniony. Jedną z wad jest to, że utknąłeś z interfejsem. Jeśli optymalizacja może być dostarczona do określonej usługi poprzez zmianę interfejsu, masz pecha, ponieważ REST tego zabrania. Z drugiej strony jednak reszta jest zoptymalizowana pod kątem sieci, stąd niesamowita popularność odpoczynku przez HTTP!

Powyższe pojęcia reprezentują definiujące cechy REST i odróżniają architekturę REST od innych architektur, takich jak usługi internetowe. Warto zauważyć, że usługa REST jest usługą internetową, ale usługa internetowa niekoniecznie jest usługą REST.

Zobacz ten blog post on zasady projektowania REST aby uzyskać więcej informacji na temat REST i wyżej wymienionych kule.

edytuj: aktualizacja treści na podstawie komentarzy

SOAP ( Simple Object Access Protocol) I REST ( Representation State Transfer) oba są piękne na swój sposób. Więc ich nie porównuję. Zamiast tego staram się przedstawić obraz, kiedy wolałem korzystać z odpoczynku, a kiedy mydło.

Co to jest ładunek?

Gdy dane są wysyłane przez Internet, każda przesyłana jednostka zawiera zarówno informacje nagłówka, jak i faktyczne przesyłane dane. Nagłówek identyfikuje źródło i miejsce przeznaczenia packet, podczas gdy rzeczywiste dane są określane jako ładunek . Ogólnie rzecz biorąc, ładunek to dane, które są przenoszone w imieniu aplikacji i dane otrzymane przez system docelowy.

Teraz, na przykład, muszę wysłać Telegram i wszyscy wiemy, że koszt telegramu będzie zależał od niektórych słów.

więc powiedz mi Wśród wymienionych poniżej dwóch wiadomości, który z nich jest tańszy do wysłania?

<name>Arin</name>

Lub

"name": "Arin"

Wiem Twoja odpowiedź będzie druga, chociaż obie reprezentujące tę samą wiadomość druga jest tańsza w odniesieniu do kosztów.

Więc staram się powiedzieć, że wysyłanie danych przez sieć w formacie JSON jest tańsze niż wysyłanie ich w formacie XML w odniesieniu do ładunku.

Oto pierwsza korzyść lub zalety odpoczynku nad mydłem. SOAP obsługuje tylko XML, ale REST obsługuje inny format, taki jak text, JSON, XML itp. I już wiemy, że jeśli użyjemy Json to na pewno będziemy w lepszym miejscu jeśli chodzi o ładunek.

Teraz SOAP obsługuje tylko XML, ale ma również swoje zalety.

Naprawdę! Jak?

SOAP opiera się na XML na trzy sposoby Koperta-określa, co znajduje się w wiadomości i jak ją przetworzyć.

Zbiór reguł kodowania dla typów danych, a na koniec układ wywołań procedur i odpowiedzi zebranych.

Ta koperta jest wysyłana przez transport (HTTP / HTTPS), a RPC (Remote Procedure Call) jest wykonywane, a koperta jest zwracana z informacjami w dokumencie sformatowanym XML.

Ważną kwestią jest to, że jedną z zalet SOAP jest użycie "ogólnego" transportu, ale REST używa HTTP/HTTPS. SOAP może użyć prawie każdego transportu, aby wysłać zapytanie, ale reszta nie może. Więc tutaj mamy przewagę używania mydła.

Jak już wspomniałem w powyższym paragrafie "REST używa HTTP/HTTPS" , więc zajrzyj trochę głębiej na te słowa.

Kiedy mówimy o odpoczynku przez HTTP, wszystkie zastosowane środki bezpieczeństwa HTTP są dziedziczone, a to jest znane jako bezpieczeństwo poziomu transportu i zabezpiecza wiadomości tylko wtedy, gdy znajduje się w przewodzie, ale kiedy dostarczysz go po drugiej stronie, nie wiesz, ile etapów będzie musiał przejść, zanim dotrze do rzeczywistego punktu, w którym dane będą przetwarzane. I oczywiście, wszystkie te etapy mogą używać czegoś innego niż HTTP.Więc odpoczynek nie jest bezpieczniejszy całkowicie, prawda?

Ale SOAP obsługuje SSL podobnie jak REST dodatkowo obsługuje również WS-Security, który dodaje pewne funkcje bezpieczeństwa dla przedsiębiorstw. WS-Security oferuje ochronę przed tworzeniem Wiadomości do jej konsumpcji . Tak więc dla bezpieczeństwa na poziomie transportu wszelkie luki, które odkryliśmy, że można zapobiec za pomocą WS-Security.

Poza tym, ponieważ REST jest ograniczony przez protokół HTTP więc obsługa transakcji nie jest kwasem zgodny, ani nie może zapewnić dwufazowego commit w rozproszonych ponadnarodowych zasobów.

Ale SOAP ma kompleksowe wsparcie zarówno dlazarządzania transakcjami na bazie kwasu dla transakcji krótkotrwałych i zarządzania transakcjami na podstawie rekompensaty dla transakcji długoterminowych. Obsługuje również dwufazowe commity w rozproszonych zasobach .

Nie wyciągam żadnych wniosków, ale wolę SOAP-based web service podczas bezpieczeństwa, transakcji, itp. są głównymi obawy.

Oto "the Java EE 6 Tutorial", gdzie powiedzieli RESTful design może być odpowiedni, gdy spełnione są następujące warunki. Spójrz.

mam nadzieję, że podobało ci się czytanie mojej odpowiedzi.

Odpoczynek(RE presentational S tate T ransfer)
Odpoczynek to styl architektoniczny. Nie definiuje tak wielu standardów jak mydło. Facebook API, Google Maps API) przez internet do obsługi operacji CRUD na danych. REST koncentruje się na dostępie do nazwanych zasobów poprzez jeden spójny interfejs.

Mydło(S imple O bject A ccess P rotocol)
Mydło przynosi swoje własny protokół i skupia się na ujawnianiu elementów logiki aplikacji (nie danych) jako usług. Mydło eksponuje operacje. SOAP koncentruje się na dostępie do nazwanych operacji, każda operacja implementuje jakąś logikę biznesową. Chociaż SOAP jest powszechnie określany jako web services jest to błędna nazwa. Mydło ma niewiele wspólnego z siecią. REST dostarcza prawdziwe Usługi internetowe oparte na Uri i HTTP.

Po co odpoczywać?

• ponieważ REST używa standardowego HTTP to jest znacznie prostsze w prawie zawsze sposób.
• REST jest łatwiejszy do wdrożenia, wymaga mniejszej przepustowości i zasobów.
• REST pozwala na wiele różnych formatów danych, gdzie SOAP zezwala tylko na XML.
• REST pozwala na lepszą obsługę klientów przeglądarek dzięki obsłudze JSON.
• REST ma lepszą wydajność i skalowalność. Odczyty REST mogą być buforowane, odczyty oparte na SOAP nie mogą być buforowane.
• jeśli bezpieczeństwo nie jest głównym problemem i mamy ograniczone zasoby. Albo chcemy stworzyć API, które będzie łatwo używane przez innych programistów publicznie, wtedy powinniśmy przejść z resztą.
• jeśli potrzebujemy Bezpaństwowych operacji CRUD, to idź z odpoczynkiem.
[37]}REST jest powszechnie używany w mediach społecznościowych, czacie internetowym, usługach mobilnych i publicznych interfejsach API, takich jak Google Maps.
• RESTful service zwraca różne typy Mediatypów dla tego samego zasobu, w zależności od parametru nagłówka żądania "Accept" jako application/xml LUB application/json dla POST i /user/1234.json lub GET /user/1234.xml dla GET.
• reszta usługi mają być wywoływane przez aplikację po stronie klienta, a nie bezpośrednio przez użytkownika końcowego.
• ST w spoczynku pochodzi z S tate T ransfer. Przenoszenie stanu zamiast przechowywania go przez serwer sprawia, że usługi REST są skalowalne.

Dlaczego mydło?

• SOAP nie jest łatwy w implementacji i wymaga większej przepustowości i zasobów.
• żądanie wiadomości SOAP jest przetwarzane wolniej niż REST i nie używa mechanizmu buforowania sieci.
• WS-Security: podczas gdy SOAP obsługuje SSL (podobnie jak REST), obsługuje również WS-Security, który dodaje pewne funkcje zabezpieczeń dla przedsiębiorstw.
• WS-AtomicTransaction: potrzebujesz ACID Transactions nad usługą, będziesz potrzebował SOAP.
• WS-ReliableMessaging: Jeśli Twoja aplikacja wymaga asynchronicznego przetwarzania oraz gwarantowanego poziomu niezawodności i bezpieczeństwa. Rest nie ma standardowego komunikatora system i oczekuje, że klienci radzą sobie z awariami komunikacji poprzez ponowną próbę.
• jeśli Bezpieczeństwo jest poważnym problemem, a zasoby nie są ograniczone, powinniśmy skorzystać z usług internetowych SOAP. Podobnie jak jeśli tworzymy serwis internetowy dla bram płatniczych, prac związanych z finansami i telekomunikacją, powinniśmy pójść z SOAP, ponieważ tutaj potrzebne jest wysokie bezpieczeństwo.

Source1
source2

Decyzja między nimi będzie twoim pierwszym wyborem w projektowaniu serwisu internetowego, dlatego ważne jest, aby zrozumieć zalety i wady tych dwóch. Ważne jest również, w czasem gorącej debacie między obiema filozofiami, oddzielenie rzeczywistości od retoryki.

Podstawy odpoczynku

Wszystko w spoczynku jest uważane za zasób.
• każdy zasób jest identyfikowany przez URI.
• używa jednolitych interfejsów. Zasoby są obsługiwane za pomocą POST, GET, Operacje PUT, DELETE, które są podobne do operacji Create, Read, Update I Delete (CRUD).
Bądź bezpaństwowcem. Każde żądanie jest niezależnym żądaniem. Każde żądanie od klienta do serwera musi zawierać wszystkie informacje niezbędne do zrozumienia żądania.
• komunikacja odbywa się za pośrednictwem reprezentacji. Np. XML, JSON RESTful Web Services. Usługi sieciowe RESTful oparte są na metodach HTTP i koncepcji REST. RESTful web service zazwyczaj definiuje bazowy URI dla usługi; obsługiwane typy MIME (XML, text, JSON, user-defined, ...) oraz zestaw operacji (POST, GET, PUT, DELETE), które są obsługiwane.

Podstawy mydła

• WSDL definiuje umowę między Klientem a usługą i jest statyczna ze swej natury.
SOAP buduje protokół oparty na 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 natywne wsparcie dla SOAP, zazwyczaj podaje się mu adres URL usługi internetowej i można wywołać jej funkcje usługi internetowej bez potrzeby stosowania określonego kodu.
• dane binarne, które są wysyłane, muszą być najpierw zakodowane w formacie takim jak Base64 zakodowane.
Posiada kilka protokołów i technologii z nim związanych: WSDL, XSD, SOAP, WS-Addressing.

Mydło a odpoczynek?

Jedną z głównych zalet mydła czy masz Opis usługi WSDL. Można w zasadzie odkryć usługę automatycznie i wygenerować użyteczny serwer proxy klienta z tego opisu usługi(wygenerować wywołania usługi, niezbędne typy danych dla metod i tak dalej). Zauważ, że w wersji 2.0 WSDL obsługuje wszystkie czasowniki HTTP i może być również używany do dokumentowania usług RESTful, ale istnieje mniej słowna alternatywa w WADL (język opisu aplikacji internetowych) do tego celu.

Z Odpoczynkiem usługi, bezpieczeństwo wiadomości jest dostarczane przez protokół transportowy (HTTPS) i jest tylko punkt-punkt. Nie ma standardowego systemu przesyłania wiadomości i oczekuje, że klienci radzą sobie z awariami komunikacji poprzez ponowną próbę. SOAP ma wbudowaną logikę udanych / ponownych prób i zapewnia kompleksową niezawodność nawet dzięki pośrednikom mydła.

Jedną z głównych zalet RESTful API jest to, że jest elastyczny dla reprezentacji danych, na przykład, można serializować dane w formacie XML lub JSON. Interfejsy API RESTful są czystsze lub łatwiejsze do zrozumienia, ponieważ dodają element używania znormalizowanych Uri i nadają znaczenie CZASOWNIKOWI HTTP (np. GET, POST, PUT i DELETE).

Usługi RESTful są również lekkie, czyli nie mają zbyt wielu dodatkowych znaczników XML. Aby wywołać RESTful API wystarczy przeglądarka lub stos HTTP i prawie każde urządzenie lub urządzenie podłączone do sieci ma to.

Zalety odpoczynku

• ponieważ REST wykorzystuje standard HTTP, jest to znacznie prostsze pod każdym względem. Tworzenie klientów, tworzenie interfejsów API, dokumentacja jest znacznie łatwiejsza do zrozumienia i nie ma zbyt wielu rzeczy, których reszta nie robi łatwiej/lepiej niż SOAP.
• REST pozwala na wiele różnych formatów danych, podczas gdy SOAP zezwala tylko na XML. Chociaż może się to wydawać, że dodaje złożoności odpoczynkowi, ponieważ musisz obsługiwać wiele formatów, z mojego doświadczenia wynika, że było to bardzo korzystne. JSON zwykle lepiej pasuje do danych i parsuje dużo szybciej. REST pozwala na lepszą obsługę klientów przeglądarek dzięki obsłudze JSON.
REST ma lepszą wydajność i skalowalność. Odczyty REST mogą być buforowane; odczyty oparte na SOAP nie mogą być buforowane.
• żadne drogie narzędzia nie wymagają interakcji z serwisem WWW
• mniejsza krzywa uczenia się
• Efficient (SOAP używa XML dla wszystkich wiadomości, REST może używać mniejszych formatów wiadomości)
• Szybki (nie wymaga intensywnego przetwarzania)
[7]}bliżej innych technologii internetowych w projektowaniu filozofia

Zalety mydła

• WS-Security: podczas gdy SOAP obsługuje SSL (podobnie jak REST), obsługuje również WS-Security, który dodaje pewne funkcje zabezpieczeń dla przedsiębiorstw. Obsługuje tożsamość poprzez pośredników, a nie tylko punkt do punktu (SSL). Zapewnia również standardową implementację integralności danych i prywatności danych. Nazywanie go "Enterprise" nie oznacza, że jest bezpieczniejszy, po prostu obsługuje niektóre narzędzia bezpieczeństwa, których typowe usługi internetowe nie potrzeba, w rzeczywistości, są one potrzebne tylko w kilku scenariuszach "enterprise".
• WS-AtomicTransaction: potrzebujesz ACID Transactions nad usługą, będziesz potrzebował SOAP. Podczas gdy REST obsługuje transakcje, nie jest tak kompleksowy i nie jest zgodny z ACID. Na szczęście transakcje ACID prawie nigdy nie mają sensu przez internet. REST jest ograniczony przez sam HTTP, który nie może zapewnić dwufazowego commita w rozproszonych zasobach transakcyjnych, ale SOAP może. Aplikacje internetowe tego nie potrzebują poziom niezawodności transakcji, aplikacje korporacyjne czasami tak.
• WS-ReliableMessaging: Rest nie ma standardowego systemu przesyłania wiadomości i oczekuje, że klienci będą radzić sobie z awariami komunikacji poprzez ponowną próbę. SOAP ma wbudowaną logikę udanych / ponownych prób i zapewnia kompleksową niezawodność nawet dzięki pośrednikom mydła.
W przeciwieństwie do innych systemów, w których nie ma dostępu do Internetu, nie ma dostępu do Internetu.]}
• działa dobrze w rozproszonych środowiskach korporacyjnych (reszta zakłada bezpośrednia komunikacja punkt-punkt)
• standaryzowane
• zapewnia znaczną rozszerzalność przed montażem w postaci standardów WS
• Wbudowana obsługa błędów
• Automatyzacja przy użyciu niektórych produktów językowych

Gdzie korzystać z odpoczynku

Obszary, w których odpoczynek działa dobrze to:

• ograniczona przepustowość i zasoby: pamiętaj, że struktura zwrotu jest naprawdę w dowolnym formacie (zdefiniowanym przez programistę). Dodatkowo każda przeglądarka może być używane, ponieważ podejście REST wykorzystuje standardowe czasowniki GET, PUT, POST i DELETE. Ponownie, pamiętaj, że REST może również korzystać z obiektu XMLHttpRequest, który obecnie obsługuje większość nowoczesnych przeglądarek, co dodaje bonus AJAX.
• bezstanowe operacje: Jeśli operacja musi być kontynuowana, to odpoczynek nie jest najlepszym podejściem i SOAP może lepiej do niej pasować. Jeśli jednak potrzebujesz bezpaństwowych operacji CRUD (twórz, Czytaj, Aktualizuj i usuwaj), to jest to reszta.
• buforowanie sytuacje: Jeśli informacje mogą być buforowane z powodu bezpaństwowego działania podejścia REST, jest to idealne.

Gdzie używać mydła

Obszary, w których mydło sprawdza się jako świetne rozwiązanie:

• asynchroniczne przetwarzanie i wywoływanie: Jeśli Twoja aplikacja potrzebuje gwarantowanego poziomu niezawodności i bezpieczeństwa, SOAP 1.2 oferuje dodatkowe standardy, aby zapewnić tego typu działanie. Rzeczy jak WSRM-ws-niezawodny Wiadomości.
• formalne umowy: jeśli obie strony (dostawca i konsument) muszą uzgodnić format wymiany, to SOAP 1.2 podaje sztywne specyfikacje dla tego typu interakcji.
• Stateful operations: Jeśli aplikacja potrzebuje informacji kontekstowych i zarządzania stanem konwersacyjnym, SOAP 1.2 ma dodatkową specyfikację w strukturze WS, aby wspierać te rzeczy (bezpieczeństwo, transakcje, koordynacja itp.). / Align = "left" / to sprawi, że deweloperzy zbudują tę niestandardową instalację wodno-kanalizacyjną.

Różnica między odpoczynkiem a mydłem

Mydło

Mydło jest protokołem.
1. soap oznacza Simple Object Access Protocol.
2. SOAP nie może używać REST, ponieważ jest to protokół.
SOAP wykorzystuje interfejsy usług do ujawniania logiki biznesowej.
3. SOAP definiuje standardy, których należy ściśle przestrzegać.
SOAP wymaga większej przepustowości i zasobów niż reszta. SOAP definiuje własne bezpieczeństwo.
4. SOAP pozwala na format danych XML tylko.
Mydło jest mniej korzystne niż odpoczynek.

Reszta

Odpoczynek to styl architektoniczny.
1. REST oznacza Reprezentacyjny Transfer Państwa.
2. REST może korzystać z usług internetowych SOAP, ponieważ jest to koncepcja i może używać dowolnego protokołu, takiego jak HTTP, SOAP.
3. REST używa URI do ujawniania logiki biznesowej.
4. odpoczynek nie definiuje zbyt wielu standardów jak mydło.
5. odpoczynek wymaga mniejszej przepustowości i zasobów niż SOAP.
6. RESTful web usługi dziedziczą środki bezpieczeństwa z transportu podstawowego.
7. REST pozwala na różne formaty danych, takie jak zwykły tekst, HTML, XML, JSON itp.
Odpoczynek bardziej preferowany niż mydło.

Po więcej szczegółów zobacz tutaj

IMHO nie można porównywać Mydła i odpoczywać gdzie to są dwie różne rzeczy.

SOAP jest protokołem, a REST jest wzorcem architektury oprogramowania. W Internecie jest wiele nieporozumień na temat SOAP vs REST .

SOAP definiuje format wiadomości oparty na XML, którego aplikacje obsługujące usługi sieciowe używają do komunikowania się ze sobą przez internet. Aby to zrobić, aplikacje wymagają uprzedniej wiedzy o umowie wiadomości, typy danych, itd..

REST przedstawia stan (jako zasoby) serwera z URL.It jest bezpaństwowy, a klienci nie powinni mieć wcześniejszej wiedzy na temat interakcji z serwerem poza rozumieniem hypermedia.

Dodanie dla:

++ błąd często popełniany przy zbliżaniu się do REST to myślenie o REST jako o "usługach internetowych z adresami URL"-myślenie o REST jako o innym mechanizmie zdalnego wywołania procedury (RPC), takim jak SOAP, ale wywoływanym przez zwykłe adresy URL HTTP i bez ogromnych przestrzeni nazw SOAP XML.

++ przeciwnie, reszta ma niewiele wspólnego z RPC. Podczas gdy RPC jest zorientowany na usługi i koncentruje się na działaniach i czasownikach, reszta jest zorientowana na zasoby, podkreślając rzeczy i rzeczowniki, które składają się na podanie.

Wśród wielu innych już omówionych odpowiedzi, chciałbym podkreślić, że SOAP umożliwia definiowanie umowy, WSDL, które definiują obsługiwane operacje, złożone typy itp. Mydło jest zorientowane na operacje, ale reszta jest zorientowana na zasoby. Osobiście wybrałbym SOAP dla złożonych interfejsów między wewnętrznymi aplikacjami korporacyjnymi, a REST dla publicznych, prostszych, bezpaństwowych interfejsów ze światem zewnętrznym.

Wiele z tych odpowiedzi zupełnie zapomniało wspomnieć o sterowaniu hypermedia (HATEOAS), które jest całkowicie fundamentalne dla odpoczynku. Kilku innych dotyczyło tego, ale nie wyjaśniło tego tak dobrze.

Ten artykuł powinien wyjaśnić różnicę między pojęciami, bez wnikania w chwasty na konkretnych cechach mydła.

• SOAP jest protokołem, podczas gdy REST jest architekturą.
• SOAP eksponuje zachowanie reprezentujące logikę, podczas gdy REST eksponuje zasoby reprezentujące dane.
[[6]}pod względem konsumpcji usługa odpoczynku jest znacznie prostsza niż mydło. Z resztą overhead obsługi koperty XML jest wyeliminowany, co sprawia, że szybciej niż w porównaniu do SOAP.
• SOAP zapewniało dobre opcje bezpieczeństwa w porównaniu do odpoczynku.
• do interakcji Maszyna-Maszyna & rozwiązania korporacyjne SOAP jest preferowane, ale dla publicznych interfejsów API REST jest najlepszą opcją prawie 70% publicznych interfejsów API to REST.
• reszta jest lekka, łatwa w utrzymaniu i skalowalna.
• REST jest niezależny od urządzenia, tzn. klient korzystający z REST API może być dowolnym urządzeniem mobilnym, notebookiem, telewizorem itp.
• z chmurą w akcji. Aplikacja powoli przechodzi na systemy oparte na chmurze, takie jak Azure, Amazon AWS. Te systemy są budowane i odsłaniają REST API. stąd jest to dobry ruch aby zbudować aplikację na górze REST API.

Reszta Vs mydło

Po pierwsze: w luźnym znaczeniu, usługa internetowaoznacza używanie protokołu HTTP do przesyłania Danych zamiast stron internetowych. Jednak w ścisłym sensie , usługa internetowa, zdefiniowana przez W3C jest bardzo specyficzną formą tej idei. Tak więc, kiedy ludzie mówią o SOAP vs. REST , w rzeczywistości mają na myśli Usługi internetowe vs. REST (gdzie "Usługi internetowe" odnoszą się do oficjalnej definicji, ponieważ w praktyce usługi REST są również nazywane usługami sieciowymi przez wszystkich).

Załóżmy więc, że chcesz wywołać funkcję w zdalnym komputerze, zaimplementowaną w innym języku programowania (Remote procedure call / RPC). Musisz (jakoś) wysłać mu wiadomość i uzyskać odpowiedź. Po pierwsze, tę funkcję można znaleźć pod określonym adresem URL, podanym przez jej twórcę. Następnie należy rozważyć dwa główne pytania.

• jaki jest format wiadomości, którą powinieneś wysłać
• jak należy przenieść wiadomość i forth

Zgodnie z oficjalną definicją, odpowiedzią na pierwsze pytanie jest WSDL , XML, który opisuje, w szczegółowym i ścisłym formacie, jakie są parametry, jakie są ich typy, nazwy, wartości domyślne, nazwa funkcji, która ma być wywołana, itp. Na drugie pytanie są różne odpowiedzi. Najpopularniejszym (zdecydowanie) jest mydło . Jego główną ideą jest: zawiń poprzedni XML (aktualną wiadomość) w jeszcze inny XML i wyślij go przez HTTP (chociaż teoretycznie może być używany z innymi protokołami, ale nikt tego nie robi). Do wysłania wiadomości służy metoda POST HTTP, ponieważ zawsze istnieje body.

Tak więc, za pomocą podejścia (szeroko, ale błędnie) zwanego SOAP, mapujesz adres URL do funkcji, czyli akcji . Podejście RESTful jest następujące: zamiast adresu URL reprezentującego akcję, powinien on reprezentować rzecz (w żargonie RESTful nazywa się resource ). Ponieważ protokół HTTP (który już używamy) obsługuje czasowniki, użyj tych czasowników, aby określić, jakie działania wykonać na rzeczy.

Tak więc, przy podejściu SOAP (znowu błędne określenie), jeśli masz listę klientów i chcesz wyświetlić/zaktualizować / usunąć jednego, będziesz miał 3 adresy URL: {]}

• myapp/read-customer i w treści wiadomości podaj id klienta do odczytu.
• myapp/update-customer i w ciele, podaj identyfikator klienta, a także nowe dane
• myapp/delete-customer i id w body

Podczas gdy, z resztą podejścia, można mieć tylko myapp/customers/3 (Gdzie 3 jest id konkretnego klienta). Aby wyświetlić dane Klienta, naciśnij adres URL z żądaniem GET. Aby go usunąć, ten sam URL , z czasownikiem DELETE. Aby go zaktualizować, Ponownie, ten sam adres URL z czasownikiem POST i nową treścią w treści żądania.

Aby uzyskać więcej informacji na temat wymagań, jakie musi spełnić usługa, aby została uznana za prawdziwie wypoczętą, zobacz[62]}Richardson model dojrzałości . Artykuł podaje przykłady i, co ważniejsze, wyjaśnia, dlaczego (tak zwana) usługa SOAP jest usługą odpoczynku poziomu 0 (chociaż poziom 0 oznacza niską zgodność z tym modelem, nie jest obraźliwa i nadal jest przydatna w wielu przypadkach).