Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein
SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der
WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre
SOAP zu viel.
Bei JSON/REST brauch ich keine in JSON/REST implementierte Sicherheitslösung/Spezifikation. Ich nehme einfach das, was es schon seit Jahrzehnten gibe.
Ich Ruf eine
URL auf und ob ich diese Aufruf erlaubt ist wird außerhalb meiner JSON/REST-Schnittstelle gelöst. Ich kann mich voll und ganz auf die eigene Logik konzentrieren.
Und solche Security-Lösung auf
URL-Basis gibt es wie Sand am Meer.
Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten und warum ist es besser auf eine einheitliche Spezifikation zu verzichten? Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss, dann ist es für mich das gegenteil von ganz auf die eigene Businesslogik zu konzentrieren. In
SOAP ist dieses Verfahren genau spezifiziert und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar. 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. Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.