it-swarm.dev

Wie kann ich meinen Chef davon überzeugen, REST über SOAP zu verwenden?

Wir müssen eine API für unser System erstellen. Wie kann ich meinen Chef davon überzeugen, dass REST eine bessere Option ist als SOAP (oder XML-RPC))?

Ich sage REST ist ...

  • einfacher zu implementieren und zu warten
  • nicht viel Neues zu lernen - einfaches altes HTTP
  • viele Leute haben es gewählt Yahoo ~ Facebook ~ Twitter
  • wird viel schneller zu codieren sein

Mein Chef sagt SOAP ist ...

  • reicher und ausdrucksvoller
  • es ist alles Standard-XML (SOAP, WSDL, UDDI) - und wird daher einfacher zu konsumieren sein
  • gut standardisiert als REST
  • Google verwendet viel SOAP
  • es ist wichtig, die Standards SOAP] einzuhalten, als ein benutzerdefiniertes XML-Schema in REST zu erstellen
37
treecoder

Von einem Mann, der sowohl SOAP als auch REST ausgiebig ...

BOSS sagt SOAP ist ...

richer and more expressive

Immer wenn jemand sagt, ein Produkt sei "reich", möchte ich heftig krank werden. Ich kann mir keinen klischeehafteren Kommentar zu einer Technologie oder Plattform vorstellen. Grundsätzlich sagen Sie: "Ich finde dieses Produkt großartig, aber ich habe keine tatsächlichen Fakten, um es zu sichern." Ich weiß nicht, was er mit "ausdrucksstark" meint, also kann ich es nicht wirklich kommentieren ...

es ist alles Standard-XML (SOAP, WSDL, UDDI) - und wird daher einfacher zu konsumieren sein

Dies ist offensichtlich falsch. SOAP kann schwierig sein, insbesondere wenn Sie sich mit komplexen Typen und Authentifizierungsheadern befassen. Dies gilt insbesondere, wenn Sie mit der sprachübergreifenden Kommunikation beginnen - PHP = um einen .NET-Dienst richtig zu nutzen und mit ihm zu kommunizieren SOAP-Dienst, der komplexe Typen und Authentifizierung verwendete, war eine Übung in Tastatur-Horror, die mich bis heute in kaltem Schweiß aufwachen lässt REST ist definitiv einfacher zu konsumieren - Sie geben nur die URL an und fertig! Sie haben Ihre Daten! Dies hat einige Nachteile, abhängig von Ihren Anforderungen, aber für viele Webdienste ist dies alles, was benötigt wird.

gut standardisiert als REST

Es ist "standardisiert" durch die Tatsache, dass es ein Schema hat. Das ist es. Abgesehen davon müssen Sie immer noch mit den Daten eines anderen arbeiten, was niemals ein Picknick ist, egal welches Kommunikationsprotokoll Sie verwenden. Und REST hat einen Standard - heißt HTTP . Es funktioniert ziemlich gut.

Google verwendet viel SOAP

Sie verwendet zu verwenden SOAP (sie können für einige Produkte noch, aber nicht viele). Die Mehrheit ihrer Webdienste ist solide REST-basiert. Hier ist ein Link, der zeigt, dass sie haben einen SOAP Service zugunsten von REST aufgegeben.

es ist wichtig, die Standards SOAP] einzuhalten, als ein benutzerdefiniertes XML-Schema in REST zu erstellen

Dies klingt wie einer dieser Kommentare von Vorgesetzten mit begrenztem Verständnis der aktuellen Technologie. Es wird nur einen Teil des Pakets SOAP) geben, der standardisiert ist - den Nachrichtenkopf und den Body Wrapper. Alles dazwischen ist Ihr eigenes XML. Sie müssen noch Ihre eigene Nachricht erstellen Die Nachricht selbst entspricht nicht einem bestimmten Standard. Sie ist immer noch ein serialisiertes Objekt oder eine Gruppe von Objekten.

Zum Schluss ist SOAP versus REST ein großes Thema, eines ohne konkrete Antwort, und Sie werden wahrscheinlich unterschiedliche Antworten erhalten, je nachdem, mit wem Sie sprechen Tatsächlich kann ich nicht mit Sicherheit sagen , dass in Ihrem speziellen Fall REST [~ # ~] wird [~ # ~] besser sein, aber ich kann sagen, dass die Argumente Ihres Chefs schwach sind und auf ein Unverständnis über die Unterscheidung zwischen den beiden hinweisen Ich habe beide Technologien verwendet und meine harte und schnelle Schlussfolgerung lautet: Es gibt keine feste und schnelle Schlussfolgerung und wie so viele andere technische Entscheidungen hängt sie von den Anforderungen der Organisation ab. Die beste Lösung ist wirklich durchdachte Forschung. eine offene Diskussion zwischen den Personen, die an dem Projekt arbeiten, um die beste Lösung zu finden, und einen ehrlichen Blick auf Ihre Bedürfnisse.

Hier einige Links zu bestehenden Diskussionen, die von Vorteil sein können.

https://stackoverflow.com/questions/3285704/should-a-netflix-or-Twitter-style-web-service-use-rest-or-soap

http://www.prescod.net/rest/rest_vs_soap_overview/

https://stackoverflow.com/questions/209905/rest-and-soap

66
Jarrod Nettles

Seife oder Ruhe? Andere Antworten helfen Ihnen dabei, den Punkt aus technischer Sicht zu argumentieren. Ich gehe jedoch davon aus, dass ein KO unwahrscheinlich ist, nur weil Sie technisch gesehen die meisten Dinge mit beiden Ansätzen tun können. Es gibt einige Ausnahmen, die zu einem technischen Knockout führen können, z.

  • wenn API-Anforderungen über externe Messaging-Middleware routingfähig sein sollen und der Empfänger dennoch den ursprünglichen Absender authentifizieren und überprüfen kann, gewinnt SOAP
  • wenn Sie die Authentifizierungs- und Zugriffssteuerungslogik Ihrer vorhandenen Anwendung verwenden möchten, kann REST praktisch ein NOP sein, während SOAP ein eigenständiges Miniprojekt sein kann.

Wenn Sie eine dieser außergewöhnlichen Anforderungen nicht als ein Muss haben und da Sie nicht der Boss (!) Sind, ist das Beste, auf das Sie hoffen können, ein Unentschieden, denn obwohl die Entscheidung "technisch" erscheint, bleibt sie bestehen subjektiv.

Aber ... wenn Sie die beste Entscheidung treffen möchten (und nicht nur ein Argument gewinnen möchten), können Sie dies vielleicht mit Ihrem Chef auf eine andere Art und Weise betrachten:

Da Sie "eine API für unser System erstellen müssen", schließe ich, dass dies nicht nur ein internes technisches Detail Ihres Systems ist und "Technische Argumente sind für technische Personen - auch bekannt als Personen, die die Arbeit erledigen". t bewerben. Es gibt irgendwo da draußen eine Gruppe von Leuten, die sich mit allem befassen müssen, was Sie liefern, und ich denke, Sie möchten wahrscheinlich, dass sie es benutzen und es lieben? Wenn ja:

Was sie für die API benötigen, übertrumpft wahrscheinlich alle Argumente, die Sie oder Ihr Chef vorbringen können (zumindest würden sie das so denken)

z.B. Wenn sie über BizTalk oder ähnliches in Ihre API integriert werden möchten, ist dies möglicherweise SOAP (Dokumentliteral und alle). Aber wenn es sich um Codierer handelt, die in Ihre API schreiben, kann SOAP der Todesstoß für die Adoption sein, während REST Sie zu Helden macht.

Wenn Sie bereits wissen, wer diese Personen sind, sollten Sie sie meiner Meinung nach von einer API fragen, was sie benötigen. Wenn es sich um einen "neuen Markt" handelt, versuchen Sie vielleicht, die besten Vertreter zu finden, die Sie finden können, oder versuchen Sie zumindest zu beschreiben und zu verstehen, wie die "repräsentative Kundenumgebung" aussehen wird, um die Entscheidung zu treffen.

Mit anderen Worten, ich würde Ihnen empfehlen, zu prüfen, ob Sie die Kundenstimme entweder von echten externen Kunden oder von anderen in der Organisation oder von Partnern finden können, die vor dem Start einen guten Zwischenjob erledigen können.

(Wenn sie dir dann sagen "REST! ​​Wagen Sie es nicht, uns etwas Rube Goldberg SOAP Monstrosität zu geben", können Sie Ihren Chef wissentlich anlächeln)

14
tardate

Es ist ein zweistufiger Prozess:

  1. Überzeugen Sie Ihren Chef, dass das technische Team die technische Richtung wählen sollte, nicht das Management.

  2. Wählte REST. Oder Seife. Oder POX. Oder Wasauchimmer.

Technische Argumente sind für technische Leute - auch bekannt als Leute, die die Arbeit machen werden. Sobald der Chef beginnt, sich für die Technologie zu entscheiden, haben Sie ein soziales Problem. Sie müssen Ihren Chef davon überzeugen, seine Hände aus dem Kuchen zu holen, und Sie Ihren Job machen lassen.

7
Sean McMillan

Ich würde einen Test vorschlagen: Code zwei Lösungen, die den gleichen sehr einfachen Service leisten. Verwenden Sie SOAP und eine REST-vollständige API und vergleichen Sie die Ergebnisse. Angesichts der heutigen Toolsets sollte es keinen großen Unterschied geben. Sie können einen Service ziemlich einfach einrichten.

Als nächstes ändern Sie die API. Ich habe die Erfahrung gemacht, dass ein Entwickler, der eine REST API) ändert, die Änderungen leicht vornehmen kann, da er sich mit einem konzeptionellen Protokoll befasst, das er versteht. Es ist auch meine Erfahrung, dass die SOAP API ist auf Tools angewiesen, um alles zu erreichen. Sie können dies von Hand tun, aber nur sehr wenige Leute tun dies (aus offensichtlichen Gründen), sobald Sie Code/Markup sehen, der generiert wird.

Besser noch ... lassen Sie Ihren Chef die SOAP Implementierung) durchführen.

4
Ken Brittain

Sie sollten sich die verschiedenen Umgebungen ansehen, in denen Ihr System verwendet wird, und wenn diese Umgebungen die Kommunikation zwischen Systemen hauptsächlich auf ruhige Weise durchführen, sollte Ihr System auch eine solche Schnittstelle bieten. (Das heißt, wenn Ihre Kunden es verwenden, sollte es auch Ihr System tun.)

2
Benni

Anstatt auf die Argumente von Perpetual Boss vs Coder einzugehen, nehmen wir einige spezifische Fälle und bewerten die Eignung des Modells. REST Liebhaber können gerne mit logischen und faktenbasierten Argumenten widerlegen -

Zweck: Remoting von Diensten/Überwindung von Firewall-Einschränkungen/Bindung mit Protokollen wie HTTP

Optionen: SOAP/REST (Verwerfen von Protokollen wie RMI usw., da dies nicht im Zusammenhang steht)

anwendungsfall 1: Ich benötige aus mehreren Gründen eine optimierte Bindung (JMS/RMI), z. B. a) Weitergabe des Transaktionskontexts b) Austausch großer Nutzdaten c) Stringente QoS Hier wähle ich SOAP. Ich habe jemanden gesehen, der über Interoperabilitätsprobleme bei komplexen Typen erwähnt wurde. Bitte erläutern Sie, warum Ihrer Meinung nach die grundlegende Profilkonformität von WS-I für Ihr Problem nicht gelöst werden kann (mit Beispiel vorzugsweise).

anwendungsfall 2: Ich benötige die Weitergabe von Identität (Assertion) in einer Verbundumgebung vertrauenswürdiger Vermittler (aktiv oder passiv). Dies ist ein B2B-Anwendungsfall. Ich glaube nicht, dass ich eine definierte Methode zum Anhängen von Richtlinien an einen REST Endpunkt) habe. Daher wird der SOAP-basierte Service zur offensichtlichen Wahl

anwendungsfall 3: Ich benötige eine Verwaltungs-API für mein PaaS. JMX-MBeans sind als Dienste verfügbar zu machen. Dies ist eine Art Punkt zu Punkt in der Natur. Die Bandbreite ist eine Einschränkung. Governance ist kein Problem. Der browserbasierte Client macht es benutzerfreundlicher. HTTPS ist in diesem Fall gut genug. Ich muss mir keine Sorgen um die Sicherheit auf Nachrichtenebene machen. Ich werde eine Auswahl treffen REST, da ich die Feinheiten und Komplexitäten von SOAP in diesem speziellen Fall nicht brauche).

anwendungsfall 4: Ich benötige zuverlässige Nachrichtenunterstützung. WS-RM kann das lösen. SOAP ist hier das offensichtliche Modell, da die SOAP Engine/App Server OOTB Unterstützung für die WS-RM-Konfiguration) hat.

anwendungsfall 5: Ich muss mehrere Endpunkte in einem TX-Kontext aufrufen, und HTTP ist die einzige verfügbare Option für das Transportprotokoll. Ich glaube nicht, dass REST WS-AT unterstützt, daher gehe ich mit SOAP

anwendungsfall 6: Ich benötige einen asynchronen Endpunkt. Ich möchte den anfordernden Thread nicht unnötig aufhalten. SOAP wird die Wahl sein.

anwendungsfall 7: Ich möchte den unnötigen Aufwand für die Konvertierung von XML in Typen beseitigen, da die Daten ohnehin mit minimaler oder keiner Transformation auf einer Benutzeroberfläche landen. REST mit JSON wäre meine Wahl.

Wenn ich an DATA/RESOURCE denke, würde ich im Allgemeinen REST Wenn ich an Operationen/Methoden denke (sync/async .. state..message level security..scalability) I. geneigt sein, SOAP zu verwenden

Lassen Sie mich nicht die Governance und SOA Winkel hier) einbringen. Ich möchte später nicht wie "einer von denen" in einem Forum klingen, das Entwicklern gewidmet ist.

Fühlen Sie sich frei, mich auf den oben genannten zu korrigieren ..

1
Adi_bea

Einer der wichtigen Vorteile von REST, der nicht ausgelöst wurde, ist, dass es zwischenspeicherbar und leicht skalierbar ist. SOAP ist nicht zwischenspeicherbar, da es ein POST Anfrage.

0
nicodemus13