SOAP vs REST (różnice)

Czytałem artykuły o różnicach między SOAP a REST jako protokołem komunikacji usług sieciowych, ale myślę, że największe zalety REST w stosunku do SOAP to:

1. REST jest bardziej dynamiczny, nie trzeba tworzyć i aktualizować UDDI (opis uniwersalny, wykrywanie i integracja).

2. REST nie jest ograniczony tylko do formatu XML. Usługi sieciowe RESTful mogą wysyłać zwykły tekst / JSON / XML.

Ale SOAP jest bardziej znormalizowany (np. Bezpieczeństwo).

Czy mam rację w tych punktach?

Niestety, istnieje wiele dezinformacji i nieporozumień wokół REST. Nie tylko twoje pytanie i odpowiedź @cmd odzwierciedlają je, ale większość pytań i odpowiedzi związanych z tematem w przepełnieniu stosu.

SOAP i REST nie mogą być bezpośrednio porównywane, ponieważ pierwszy jest protokołem (a przynajmniej próbuje być), a drugi to styl architektoniczny. Jest to prawdopodobnie jedno ze źródeł nieporozumień, ponieważ ludzie nazywają REST dowolnym API HTTP, który nie jest SOAP.

Pchając trochę rzeczy i próbując ustalić porównanie, główna różnica między SOAP a REST polega na stopniu sprzężenia między implementacjami klienta i serwera. Klient SOAP działa jak niestandardowa aplikacja komputerowa ściśle związana z serwerem. Istnieje ścisła umowa między klientem a serwerem i oczekuje się, że wszystko się zepsuje, jeśli którakolwiek ze stron coś zmieni. Po każdej zmianie potrzebujesz ciągłych aktualizacji, ale łatwiej jest ustalić, czy umowa jest przestrzegana.

Klient REST przypomina bardziej przeglądarkę. Jest to ogólny klient, który umie korzystać z protokołu i standardowych metod, a aplikacja musi się w nim zmieścić. Nie naruszasz standardów protokołu, tworząc dodatkowe metody, wykorzystujesz standardowe metody i tworzysz z nimi działania na swoim typie mediów. Jeśli zostanie to zrobione prawidłowo, będzie mniej sprzężeń, a zmiany będą łatwiejsze do rozwiązania. Klient powinien wejść do usługi REST z zerową znajomością interfejsu API, z wyjątkiem punktu wejścia i typu nośnika. W SOAP klient potrzebuje wcześniejszej wiedzy na temat wszystkiego, czego będzie używał, inaczej nie rozpocznie nawet interakcji. Ponadto klienta REST można rozszerzyć za pomocą kodu na żądanie dostarczanego przez sam serwer,

Myślę, że są to kluczowe punkty, aby zrozumieć, na czym polega REST i czym różni się od SOAP:

• REST jest niezależny od protokołu. Nie jest sprzężony z HTTP. Aplikacja REST może korzystać z dowolnego protokołu, dla którego istnieje ustandaryzowany schemat URI, podobnie jak można użyć łącza ftp na stronie internetowej.

• REST nie jest mapowaniem metod CRUD na metody HTTP. Przeczytaj tę odpowiedź, aby uzyskać szczegółowe wyjaśnienie na ten temat.

• REST jest tak ustandaryzowany jak używane części. Bezpieczeństwo i uwierzytelnianie w HTTP są ustandaryzowane, więc tego używasz podczas REST przez HTTP.

• Reszta nie jest REST bez hipermediów i hateoas . Oznacza to, że klient zna tylko identyfikator URI punktu wejścia, a zasoby powinny zwracać łącza, za którymi powinien podążać klient. Te fantazyjne generatory dokumentacji, które podają wzorce URI dla wszystkiego, co można zrobić w interfejsie API REST, zupełnie nie mają sensu. Nie tylko dokumentują coś, co powinno być zgodne ze standardem, ale kiedy to robisz, łączysz klienta z jednym szczególnym momentem ewolucji interfejsu API, a wszelkie zmiany w interfejsie API muszą być udokumentowane i zastosowane, albo się zepsuje.

• REST to styl architektoniczny samej sieci. Po przejściu do opcji Przepełnienie stosu wiesz, czym jest Użytkownik, Pytanie i Odpowiedź, znasz rodzaje mediów, a strona internetowa zawiera linki do nich. Interfejs API REST musi zrobić to samo. Gdyby zaprojektować sieć w taki sposób, jak ludzie myślą, że należy wykonać REST, zamiast strony głównej z linkami do pytań i odpowiedzi, mielibyśmy statyczną dokumentację wyjaśniającą, że aby wyświetlić pytanie, musisz wziąć identyfikator URI stackoverflow.com/questions/<id>, zamień id na pytanie.id i wklej to w przeglądarce. To nonsens, ale tak myśli wielu ludzi REST.

Tego ostatniego punktu nie można wystarczająco podkreślić. Jeśli Twoi klienci budują identyfikatory URI na podstawie szablonów w dokumentacji i nie uzyskują linków w reprezentacjach zasobów, to nie jest REST. Roy Fielding, autor REST, jasno stwierdził w tym poście na blogu: Interfejsy API REST muszą być oparte na hipertekstie .

Mając powyższe na uwadze, zdasz sobie sprawę, że chociaż REST może nie być ograniczony do XML, aby zrobić to poprawnie z dowolnym innym formatem, musisz zaprojektować i ustandaryzować jakiś format linków. Hiperłącza są standardem w XML, ale nie w JSON. Istnieją projekty standardów dla JSON, takie jak HAL .

Wreszcie, REST nie jest dla wszystkich, a dowodem na to jest to, że większość ludzi bardzo dobrze rozwiązuje swoje problemy za pomocą interfejsów API HTTP, które błędnie nazwali REST i nigdy nie ryzykuje. REST jest czasami trudny, szczególnie na początku, ale z czasem się opłaca, dzięki łatwiejszej ewolucji po stronie serwera i odporności klienta na zmiany. Jeśli potrzebujesz czegoś szybko i łatwo zrobić, nie zawracaj sobie głowy poprawnym REST. Prawdopodobnie nie tego szukasz. Jeśli potrzebujesz czegoś, co będzie musiało pozostać online przez lata lub nawet dekady, to REST jest dla Ciebie.

RESTvs nieSOAP jest właściwym pytaniem.

RESTW przeciwieństwie SOAPto nie protokołem.

RESTto styl architektoniczny i projekt dla architektur oprogramowania sieciowego.

RESTkoncepcje nazywane są zasobami. Reprezentacja zasobu musi być bezstanowa. Jest reprezentowany przez jakiś rodzaj mediów. Niektóre przykłady typów nośników należą XML, JSONi RDF. Zasobami manipulują komponenty. Składniki żądają zasobów i manipulują nimi za pomocą standardowego jednolitego interfejsu. W przypadku HTTP ten interfejs składa się ze standardowych ops HTTP, na przykład GET, PUT, POST, DELETE.

@ Pytanie Abdulaziz za zapala fakt, że RESTi HTTPsą często 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. Zasadniczo wszystkie aplikacje zbudowane w stylu RESTful muszą być również 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.

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 zasad projektowania REST, aby uzyskać więcej informacji na temat REST i wyżej wymienionych punktów.

EDYCJA: aktualizuj zawartość na podstawie komentarzy

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ź.

REST ( RE prezentacyjny S tate T ransfer)
RE prezentacyjny S tate przedmiotu jest T ransferred jest REST czyli nie wysyłamy Object, wysyłamy stan Object. REST to styl architektoniczny. Nie definiuje tak wielu standardów jak SOAP. REST służy do udostępniania publicznych interfejsów API (tj. Facebook API, Google Maps API) przez Internet w celu obsługi operacji CRUD na danych. REST koncentruje się na dostępie do nazwanych zasobów za pośrednictwem jednego spójnego interfejsu.

SOAP ( S wyko O bject ccess P rotocol) SOAP wprowadza swój własny protokół i skupia się na wystawienie części logiki aplikacyjnej (danych), jak usługi. SOAP ujawnia operacje. SOAP koncentruje się na dostępie do nazwanych operacji, każda operacja implementuje logikę biznesową. Chociaż SOAP jest powszechnie nazywany usługami internetowymi, jest to błędne określenie . SOAP ma bardzo mało, jeśli w ogóle, związek z siecią. REST zapewnia prawdziwe usługi sieciowe oparte na identyfikatorach URI i HTTP.

Dlaczego REST?

• Ponieważ REST korzysta ze standardowego protokołu HTTP, jest on o wiele prostszy pod każdym względem.
• REST jest łatwiejszy do wdrożenia, wymaga mniejszej przepustowości i zasobów.
• REST zezwala na wiele różnych formatów danych, gdzie jako SOAP zezwala tylko na XML.
• REST umożliwia lepszą obsługę klientów przeglądarki ze względu na obsługę 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. Lub chcemy stworzyć interfejs API, który będzie łatwo używany przez innych programistów publicznie, powinniśmy przejść do REST.
• Jeśli potrzebujemy operacji bezstanowych CRUD, wybierz REST.
• REST jest powszechnie stosowany w mediach społecznościowych, czacie internetowym, usługach mobilnych i publicznych interfejsach API, takich jak Mapy Google.
• Usługa RESTful zwraca różne MediaTypes dla tego samego zasobu, w zależności od parametru nagłówka żądania „Accept” as application/xmllub application/jsonPOST i /user/1234.jsonlub GET /user/1234.xmlfor GET.
• Usługi REST mają być wywoływane przez aplikację po stronie klienta, a nie bezpośrednio użytkownika końcowego.
• ST in REST pochodzi z S tate T. ransfer. Przeniesienie stanu zamiast przechowywania go przez serwer powoduje, że usługi REST są skalowalne.

Dlaczego mydło

• SOAP nie jest bardzo łatwy do wdrożenia i wymaga większej przepustowości i zasobów.
• Żądanie komunikatu SOAP jest przetwarzane wolniej w porównaniu do REST i nie korzysta z mechanizmu buforowania WWW.
• WS-Security: Chociaż SOAP obsługuje SSL (podobnie jak REST), obsługuje również WS-Security, który dodaje pewne funkcje bezpieczeństwa dla przedsiębiorstw.
• WS-AtomicTransaction: potrzebujesz transakcji ACID w ramach usługi, będziesz potrzebować SOAP.
• WS-ReliableMessaging: Jeśli Twoja aplikacja wymaga przetwarzania asynchronicznego oraz gwarantowanego poziomu niezawodności i bezpieczeństwa. Reszta nie ma standardowego systemu przesyłania wiadomości i oczekuje od klientów rozwiązania problemów z komunikacją przez ponowienie próby.
• Jeśli bezpieczeństwo stanowi poważny problem, a zasoby nie są ograniczone, powinniśmy korzystać z usług internetowych SOAP. Podobnie jak w przypadku tworzenia usługi internetowej dla bram płatniczych, prac związanych z finansami i telekomunikacją, powinniśmy skorzystać z SOAP, ponieważ tutaj potrzebne jest wysokie bezpieczeństwo.

źródło1
źródło2

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

MYDŁO

1. SOAP to protokół.
2. SOAP oznacza Simple Object Access Protocol.
3. SOAP nie może używać REST, ponieważ jest to protokół.
4. SOAP wykorzystuje interfejsy usług do ujawnienia logiki biznesowej.
5. SOAP określa standardy, których należy ściśle przestrzegać.
6. SOAP wymaga większej przepustowości i zasobów niż REST.
7. SOAP określa własne bezpieczeństwo.
8. SOAP zezwala tylko na format danych XML.
9. SOAP jest mniej preferowany niż REST.

RESZTA

1. REST to styl architektoniczny.
2. REST to skrót od Representative State Transfer.
3. REST może korzystać z usług sieciowych SOAP, ponieważ jest to koncepcja i może używać dowolnego protokołu, takiego jak HTTP, SOAP.
4. REST używa identyfikatora URI do ujawnienia logiki biznesowej.
5. REST nie definiuje zbyt wielu standardów, takich jak SOAP.
6. REST wymaga mniejszej przepustowości i zasobów niż SOAP.
7. Usługi sieci Web RESTful dziedziczą środki bezpieczeństwa z podstawowego transportu.
8. REST pozwala na inny format danych, taki jak zwykły tekst, HTML, XML, JSON itp.
9. REST jest bardziej preferowany niż SOAP.

Aby uzyskać więcej informacji, zobacz tutaj

IMHO nie można porównać SOAP i REST, jeśli są to dwie różne rzeczy.

SOAP to protokół, a REST to wzorzec architektury oprogramowania. W Internecie występuje wiele nieporozumień dotyczących SOAP vs. REST .

SOAP definiuje format wiadomości oparty na XML, którego aplikacje obsługujące usługi sieciowe używają do wzajemnej komunikacji przez Internet. W tym celu aplikacje potrzebują wcześniejszej wiedzy na temat kontraktu komunikatu, typów danych itp.

REST reprezentuje stan (jako zasoby) serwera z adresu URL. Jest on bezstanowy i klienci nie powinni mieć wcześniejszej wiedzy na temat interakcji z serwerem poza zrozumieniem hypermedia.

Przede wszystkim: oficjalnie, poprawna pytanie byłoby web services + WSDL + SOAPvs REST.

Ponieważ chociaż usługa internetowa jest używana w luźnym tego słowa znaczeniu, gdy używa się protokołu HTTP do przesyłania danych zamiast stron internetowych, oficjalnie jest to bardzo specyficzna forma tego pomysłu. Zgodnie z definicją REST nie jest „usługą internetową”.

W praktyce jednak wszyscy to ignorują, więc zignorujmy to również

Są już odpowiedzi techniczne, więc postaram się podać trochę intuicji.

Powiedzmy, że chcesz wywołać funkcję na komputerze zdalnym, zaimplementowaną w innym języku programowania (jest to często nazywane zdalnym wywoływaniem procedury / RPC ). Załóżmy, że tę funkcję można znaleźć pod określonym adresem URL podanym przez osobę, która ją napisała. Musisz (jakoś) wysłać mu wiadomość i uzyskać odpowiedź. Tak więc należy rozważyć dwa główne pytania.

• jaki jest format wiadomości, którą powinieneś wysłać?
• jak wiadomość powinna być przenoszona tam iz powrotem

W przypadku pierwszego pytania oficjalną definicją jest WSDL . Jest to plik 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 zostać wywołana itp . Przykładowy plik WSDL pokazuje, że plik jest ludzki -czytelne (ale niełatwo).

Na drugie pytanie są różne odpowiedzi. Jednak jedynym stosowanym w praktyce jest SOAP . Jego główna idea to: zawinąć poprzedni XML (rzeczywisty komunikat) w jeszcze jeden XML (zawierający informacje o kodowaniu i inne przydatne rzeczy) i wysłać go przez HTTP. Do wysłania wiadomości używana jest metoda POST HTTP, ponieważ zawsze istnieje treść .

Główną ideą tego całego podejścia jest mapowanie adresu URL do funkcji , to znaczy do akcji . Jeśli więc masz listę klientów na jakimś serwerze i chcesz ją wyświetlić / zaktualizować / usunąć, musisz mieć 3 adresy URL:

• myapp/read-customer i w treści wiadomości podaj identyfikator klienta, który chcesz przeczytać.
• myapp/update-customer i w treści podaj identyfikator klienta, a także nowe dane
• myapp/delete-customer i identyfikator w ciele

Podejście REST postrzega rzeczy inaczej. Adres URL nie powinien reprezentować akcji, ale rzecz (zwaną zasobem w języku REST). Ponieważ protokół HTTP (którego już używamy) obsługuje czasowniki, użyj tych czasowników, aby określić, jakie działania mają zostać wykonane na rzeczy.

Tak więc, przy podejściu REST, klient 12 byłby znaleziony na URL myapp/customers/12. Aby wyświetlić dane klienta, trafiłeś w adres URL poleceniem GET. Aby go usunąć, ten sam adres URL z czasownikiem DELETE. Aby go zaktualizować, ponownie ten sam adres URL z czasownikiem POST i nowa treść w treści żądania.

Aby uzyskać więcej informacji na temat wymagań, które musi spełnić usługa, aby można ją było uznać za naprawdę RESTful, zobacz model dojrzałości Richardsona . W tym artykule podano przykłady i, co ważniejsze, wyjaśniono, dlaczego (tak zwana) usługa SOAP jest usługą REST poziomu 0 (chociaż poziom 0 oznacza niską zgodność z tym modelem, nie jest obraźliwy i nadal jest użyteczny w wielu przypadkach).

Spośród wielu innych już omówionych w wielu odpowiedziach chciałbym podkreślić, że SOAP umożliwia zdefiniowanie kontraktu, WSDL, który definiuje obsługiwane operacje, typy złożone itp. SOAP jest zorientowany na operacje, ale REST jest zorientowany na zasoby. Osobiście wybrałbym SOAP dla złożonych interfejsów między wewnętrznymi aplikacjami korporacyjnymi, a REST dla publicznych, prostszych, bezstanowych interfejsów ze światem zewnętrznym.

Dodatek do:

++ Często popełnianym błędem przy zbliżaniu się do REST jest myślenie o nim jako o „usługach internetowych z adresami URL” - aby myśleć o REST jako o innym mechanizmie zdalnego wywoływania procedur (RPC), takim jak SOAP, ale wywoływanym przez zwykłe adresy URL HTTP i bez mocnych SOAP Przestrzenie nazw XML.

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

Wiele z tych odpowiedzi całkowicie zapomniało wspomnieć o kontrolkach hipermedialnych (HATEOAS), co jest całkowicie fundamentalne dla REST. Kilku innych dotknęło go, ale tak naprawdę nie wyjaśniło tego zbyt dobrze.

W tym artykule należy wyjaśnić różnicę między pojęciami, bez wchodzenia w chwasty dotyczące określonych funkcji SOAP.