Zoals ik al
zei, vanwege het gebruiksgemak, en zoals Rutix al
aangaf, vanwege de volwassenheid van de toolset, met name aan de consumer-kant.
Een service en diens metadata (hoe te consumeren, welke structuren te gebruiken voor request en response, welke foutberichten kun je terug verwachten) beschikbaar stellen met SOAP is in .NET, Java en PHP een kwestie van enkele regels code en wellicht wat configuratie. Serializatie, authenticatie en validatie worden al voor je geregeld, net als het genereren van klassen om vanuit code gemakkelijk met de service te kunnen communiceren.
Zonder dat jij als service-aanbieder een library voor iedere consumer moet maken, is het exposen van metadata voor REST niet standaard, noch wijdverbreid geïmplementeerd. Je zal voorbeeldberichten moeten aanmaken, deze zelf up-to-date houden en hopen dat de consumer dezelfde richtlijnen zoals type mapping hanteert (hoe verstuur je een datum?).
Ik wil als consumer niet hoeven nadenken met welke HTTP-verb ik een call moet doen, welke content-type-header ik moet noemen, welke velden wel en niet gezet moeten worden en hoe de respons terugkomt en hoe HTTP wordt misbruikt (200 OK,
{ "success": "false" }, of
"Doe toch maar een POST-request naar dat overduidelijke GET-endpoint, want de GET-url wordt waarschijnlijk te lang").
Ik wil dit kunnen doen:
C#:
1
2
3
4
5
6
7
8
9
| var client = new SomeServiceClient();
var request = new FooRequest
{
Param1 = true,
Param2 = new DateTime(2015, 02, 21, 14, 59, 00),
Param3 = "bar"
};
var response = client.DoFooRequest(request); |
Waarbij de request- en responseklassen voor me worden gegenereerd en eenvoudig zijn te updaten als de service wordt aangepast. Ik wil me niet hoeven bezighouden met hoe dit bericht wordt geserializeerd en naar de service wordt gestuurd.
Maar dan zonder die krankzinnige overhead die XML met zich mee brengt, maar gewoon met lichtgewicht en leesbare JSON.
Gekkigheid natuurlijk. Die "kranzinnige overhead" van XML ten opzichte van JSON zal vast wel een factor verschil maken, maar we zijn niet allemaal duizenden berichten per seconde aan het verwerken. Leesbaarheid is ook een non-issue, mede vanwege de eerder genoemde argumenten met betrekking tot toolset: je laat je berichten door je code genereren, of je gebruikt tools die dat voor je doen. Wanneer heb jij voor het laatst een HTTP-bericht met de hand getikt?
Totdat pure performance een harde eis is, staat implementatiegemak voorop, en wat dat betreft wint SOAP het voor mij nog steeds van welke vorm van REST dan ook bij het schrijven van een nieuwe service.
Behalve "bah, XML" lees ik niet echt argumenten in je post waarom ik géén SOAP zou gebruiken.
Ik heb verder niets tegen REST en maak er ook steeds vaker gebruik van, maar zodra er tussen verschillende partijen gecommuniceerd moet worden, heeft in mijn belevingswereld SOAP nog steeds de voorkeur.
[
Voor 12% gewijzigd door
CodeCaster op 21-02-2015 15:03
]