Zarówno SOAP ( Simple Object Access Protocol ), jak i REST ( Representation State Transfer ) są piękne na swój sposób. Więc ich nie porównuję. Zamiast tego próbuję zobrazować obraz, kiedy wolałem używać REST, a kiedy SOAP.
Co to jest ładowność?
Gdy dane są przesyłane przez Internet, każda przesyłana jednostka zawiera zarówno informacje nagłówka, jak i przesyłane dane. Nagłówek identyfikuje źródło i miejsce docelowe pakietu, podczas gdy rzeczywiste dane są określane jako ładunek . Ogólnie rzecz biorąc, ładunek to dane przenoszone w imieniu aplikacji i dane odbierane 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 spośród wymienionych poniżej tych dwóch wiadomości, który jest tańszy do wysłania?
<name>Arin</name>
lub
"name": "Arin"
Wiem, że twoja odpowiedź będzie druga, chociaż obie reprezentują tę samą wiadomość, druga jest tańsza pod względem kosztów.
Próbuję więc powiedzieć, że wysyłanie danych przez sieć w formacie JSON jest tańsze niż wysyłanie ich w formacie XML pod względem ładunku .
Oto pierwsza korzyść lub zalety REST w stosunku do SOAP . SOAP obsługuje tylko XML, ale REST obsługuje różne formaty, takie jak tekst, JSON, XML itp. I już wiemy, że jeśli użyjemy Jsona, na pewno będziemy w lepszym miejscu pod względem ładunku.
Teraz SOAP obsługuje tylko XML, ale ma również swoje zalety.
Naprawdę! W jaki sposób?
SOAP opiera się na XML na trzy sposoby Envelope - która określa, co jest w komunikacie i jak go przetwarzać.
Zestaw reguł kodowania dla typów danych, a na końcu układ zebranych wywołań procedur i odpowiedzi.
Ta koperta jest wysyłana za pośrednictwem transportu (HTTP / HTTPS), wykonywane jest RPC (zdalne wywołanie procedury), a koperta jest zwracana z informacją w dokumencie w formacie XML.
Ważną kwestią jest to, że jedną z zalet SOAP jest użycie transportu „ogólnego”, ale REST używa HTTP / HTTPS . SOAP może użyć prawie dowolnego transportu do wysłania żądania, ale REST nie. Mamy więc zaletę korzystania z SOAP.
Jak już wspomniałem w powyższym akapicie „REST używa HTTP / HTTPS” , więc przejdź nieco głębiej do tych słów.
Kiedy mówimy o REST przez HTTP, wszystkie zastosowane środki bezpieczeństwa HTTP są dziedziczone, co jest znane jako bezpieczeństwo na poziomie transportu i zabezpiecza wiadomości tylko wtedy, gdy znajduje się w kablu, ale gdy 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 na wszystkich tych etapach można użyć czegoś innego niż HTTP. Czyli odpoczynek nie jest całkowicie bezpieczniejszy, 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ę od utworzenia wiadomości do jej zużycia . Tak więc dla bezpieczeństwa na poziomie transportu bez względu na znalezioną lukę, której można zapobiec za pomocą WS-Security.
Poza tym, ponieważ REST jest ograniczony protokołem HTTP, więc obsługa transakcji nie jest zgodna z ACID, ani nie może zapewnić zatwierdzania dwufazowego w rozproszonych zasobach transnarodowych.
Ale SOAP zapewnia kompleksowe wsparcie zarówno dla zarządzania transakcjami opartymi na ACID dla transakcji krótkoterminowych, jak i zarządzania transakcjami opartymi na wynagrodzeniach dla transakcji długoterminowych. Obsługuje również zatwierdzanie dwufazowe dla zasobów rozproszonych .
Nie wyciągam żadnych wniosków, ale wolę usługę internetową opartą na SOAP, podczas gdy bezpieczeństwo, transakcje itp. Są głównymi problemami.
Oto „Samouczek Java EE 6”, w którym powiedzieli, że projekt RESTful może być odpowiedni, gdy spełnione są następujące warunki . Spójrz.
Mam nadzieję, że lubisz czytać moją odpowiedź.