Dlaczego ludzie myślą, że SOAP jest przestarzałe? [Zamknięte]


20

Podczas przeglądania SO dzisiaj znalazłem to pytanie tutaj i zaczyna się od tego:

Jasne, powiesz mi, że SOAP jest depracowane i wszystko, cóż, jestem zmuszony z niego korzystać

Znalazłem wiele takich wypowiedzi w SO do tej pory, to tylko zachęciło mnie do zadania tego pytania.

REST ma swoje zastosowania, SOAP ma swoje zastosowania, w niektórych miejscach przecinają się jako funkcjonalność, ale nie można ich wzajemnie zamieniać.

Zastanawiam się więc, dlaczego ludzie myślą, że SOAP jest „przestarzałe”? Czy to ignorancja? Złożoność specyfikacji SOAP i WS- *? REST hype? Co?

Jeśli uważasz, że SOAP jest przestarzałe, powiedz mi dlaczego. Jestem ciekawy!


31
MYDŁO jest przestarzałe, ponieważ wielu z nas przeszło na żel pod prysznic. ;)
FrustratedWithFormsDesigner

4
Zobacz SOAP i Ewolucja języka .
Josh K

1
Myślę, że hammer-> nail to złożoność SOAP, a zwłaszcza specyfikacji WS- *. Te rzeczy wykraczały daleko poza przeciętne umiejętności rozumienia w branży, zanim ktokolwiek naprawdę to zauważył, i nagle oczekuje się, że ludzie wejdą do branży i ją podniosą, prawdopodobnie nie popełniali i popełniali z tego powodu poważne błędy, co spowodowało, że powiedzieli „Huh, a może po prostu użyję JSON i zapomnę o tych wszystkich zwariowanych ...”
Jimmy Hoffa,

Odpowiedzi:


18

W przypadku usług internetowych opartych na SOAP WSDL i UDDI miały być srebrną kulą. Narzędzia miały prawie automatycznie tworzyć WSDL, UDDI miał automatycznie wykrywać usługi i łączyć klientów. Żaden tak naprawdę nie wystartował. Bez tych narzędzi SOAP jest po prostu zbyt skomplikowane w porównaniu z RESTful.

Mniej więcej w tym samym czasie hype XML wygasł, zastępując go lekkim hype. SOAP to XML, a narzuty na proste wiadomości są ogromne.


6

Myślę, że to ignorancja i szum, zarówno wtedy, jak i teraz.

Aby to zakwalifikować:

  1. Wiele projektów, które kilka lat temu korzystałyby z SOAP / WS- *, nie będzie dzisiaj i nie bez powodu.

  2. Interfejsy RESTful rozwiązują wiele przypadków użycia, które są szczególnie rozpowszechnione w aplikacjach internetowych.

  3. Aplikacje „korporacyjne” dziesięć lat temu próbowały wskoczyć na modę serwisu internetowego, a następnie przypomniały sobie, że faktycznie potrzebują wielu funkcji, z których starały się uciec w swoich starszych platformach COM +, CORBA i J2EE RMI / IIOP. Wszyscy inni wciąż tego nienawidzą.


6

SOAP obiecał wspaniałe, ratujące życie, automatyczne wykrywanie, rozwiązywanie problemów, funkcje, które już nigdy nie będą działać. Jednak tak naprawdę nigdy nie dotarliśmy tak daleko. Potem pojawił się JSON i inne lekkie , proste, wieloplatformowe alternatywy, które sprawiły, że SOAP wyglądało jak głupi wybór.

To mogłoby być wspaniałe miasto, gdyby wszyscy się w nim przeprowadzili.


4

Myślę, że jest tak, ponieważ specyfikacja SOAP 1.2 odnosi się do siebie jako WS- *, a nie do SOAP. Rozróżnia on siebie (jako wysoce sformatowany system oparty na XML) i SOAP (który, jak mówi, jest kawałkiem XML, który okazuje się być nieco znormalizowany i pełen „problemów”).

więc chociaż znormalizowali go przez kilka lat, nadal jest SOAP, ale myślę, że porzucili ten termin jako podstawowy akronim.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.