Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten
z.b. Http Basic Authentication (über https)
Cookies and session management
Token in HTTP headers (z.B. OAuth 2.0)
und warum ist es besser auf eine einheitliche Spezifikation zu verzichten?
Es wird doch nicht auf eine einheitliche Spezifikation verzichtet. Es wird halt einfach eingenommen die schon (teilweise) schon sehr lange existiert.
Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss,
Musst du nicht. Diese ist letztendlich komplett außen vor. In Delphi sind über die Jahre für die ganzen schon existierenden Verfahren (wie OAuth) Komponenten dazu gekommen, so das der Implementierungsaufwand sehr überschaubar wird.
In
SOAP ist dieses Verfahren genau spezifiziert
Vermutlich Leitet auch
SOAP über ein Art Überspezifikation. Statt etwas zu verwenden das es schon gibt meint man es in
SOAP neu erfinden zu müssen.
und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar.
Dann nimm doch so ein Framework. Bei Delphi/Emba wird es in diesem Bereich sehr wahrscheinlich keine Erweiterungen geben. Dazu ist
SOAP hinter JSON/REST und Co. mittlerweile relativ unbedeutend geworden ist. Die Zukunft ist JSON/REST.
SOAP ist mittlerweilen (fast) CORBA 2.0 zu nennen.
Evtl. ist auch der Schlusssatz in diesem
Heise-Artikel ganz gut
Da REST zu diesen Thema keine Vorgaben macht (ist ja eigentlich mehr eine Architektur, darunter kann ich auch einfach
SOAP Nachrichten verschicken) steigt die Komplexität.
Klar kannst du über normale http-Abfragen auch
SOAP-Nachrichten verschicken.
Du kannst dich aber auch gleich ins Knie schießen. Kommt aufs gleiche raus.
Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.
Nö. Passiert eigentlich nicht. Es gibt eine Hand voll Standards die man Einsetzen kann. Aber den Aufwand einer Eigenentwicklung wird sich keiner antun.