Recentelijk heb ik voor een klant een analyse gemaakt voor een te ontwikkelen Web Service. Hierbij moest een keuze worden gemaakt tussen een SOAP of REST gebaseerde service en daarna moest er een selectie worden gemaakt van een framework.
Om tot een gefundeerde keuze te komen voor het webservice framework, is er een analyse gedaan van de verschillen tussen REST en SOAP en de impact voor het betreffende project.

Eerst volgt een algemeen overzicht van de voor- en nadelen van zowel SOAP als REST gebaseerde services en daarna de relevantie voor het betreffende project.

Voor- en nadelen van SOAP en REST

Voordelen van SOAP

• Er is een technische interface (WSDL) die eenduidig vastlegt hoe met de webservice kan worden gecommuniceerd.
• Er zijn goede volwassen Java frameworks beschikbaar (JAX-WS, Axis, XFire).
• JEE standaard en W3C Standaard
• Goed uitwisselbaar met niet-Java systemen (WS-I Compliance).
• Uitgebreide support voor authenticatie zoals certificaten etc..
• Code generatie voor clients (Java: wsdl2java, dotnet: wsdl.exe)

Nadelen SOAP

• Performance kan een knelpunt zijn voor complexe XML berichten (is al een minder probleem met de huidige StaX parsers).
• Lastiger testbaar (voor een tester, niet voor een ontwikkelaar) dan REST omdat er altijd een POST nodig is en dus geen URL in de browser kan worden gebruikt zoals bij REST. Dit nadeel is minimaal aangezien de response vaak in XML is. Verder zijn er open source SOAP test tools (SoapUI, Eclipse WebToolsProject) en uitstekende commerciële tools (SoapScope).
• Sommige platformen ondersteunen SOAP niet goed (zoals Ruby, hoewel met soap4r wel steeds betere support komt). In die gevallen is het eenvoudiger om een REST client te implementeren.

Voordelen REST

• Eenvoudige aanroep voor lees acties (URL gebaseerd). Gaat alleen op voor simpele CRUD (Create, Read, Update, Delete) gebaseerde applicaties.
• Betere performance doordat uitwisselformaat eenvoudiger is (minder redundantie dan SOAP).
• Business documenten kunnen direct worden opgevraagd (zoals Word, Excel). Met SOAP moeten ze gewrapped worden.
• Beter testbaar (geldt alleen voor leesacties, voor schrijfacties heb je een http POST Nodig en kun je niet zomaar als URL invoeren).

Nadelen REST

• Geen duidelijk contract (zoals een WSDL). Meestal een papieren contract.
• Geen volwassen java frameworks. Iedereen bouwt zijn eigen implementaties. Het is ook nog geen JEE standaard, hoewel hier wel werk aan wordt verricht: JSR 311.
• Niet mogelijk om automatisch clients te genereren voor een REST applicatie (geen rest2java tools). Dus meer ontwikkelinspanning.
• Authenticatie is maatwerk.

SOAP vs REST voor een specifiek project

Belangrijke punten voor dit specifieke project zijn:

• Performance.
• Ontwikkelinspanning.
• Standaardisatie in verband met onderhoud.
• Consistentie met project en andere projecten binnen de organisatie.

Performance
Deze is voor REST in principe beter dan voor SOAP. Dit voordeel is met recente SOAP frameworks nog maar minimaal door de sterk verbeterde parsers (StaX) en treedt vooral op bij complexe XML berichten. Ook dit is voor het huidige project niet relevant aangezien het om compacte data formaten zal gaan.

Conclusie: REST heeft een minimale voorkeur boven SOAP betreffende performance.

Ontwikkelinspanning
De ontwikkelingspanning voor REST is groot. Zowel op de server als aan de client moet er veel maatwerk code worden geschreven aangezien er nog geen volwassen frameworks zijn voor REST (relatief nieuwe technologie) en er geen standaarden zijn. Voor SOAP daarentegen is er sinds de JAX-WS zeer goede support voor het ontwikkelen van zowel server als client code en zijn er uitstekende frameworks beschikbaar.

Conclusie: SOAP heeft duidelijk de voorkeur boven REST als het gaat om ontwikkelkosten.

Standaardisatie
Voor REST zijn er nog geen standaarden. Er is wel een JEE standaard in de maak (JSR 311), maar die is voorlopig niet beschikbaar. SOAP daarentegen is zowel een W3C standaard als een JEE standaard (JAX-WS).

Conclusie: SOAP heeft grote voorkeur boven REST betreffende standaardisatie.

Consistentie met project
Binnen het betreffende project zijn er al meerdere webservices ontwikkeld waarbij er gebruik wordt gemaakt van SOAP. Om het project onderhoudbaar te houden, is het van belang zo weinig mogelijk nieuwe technologieën te introduceren.
Daarnaast wordt SOAP op in vele andere projecten binnen de organisatie gebruikt en is er dus veel ervaring mee.

Conclusie: SOAP heeft de voorkeur boven REST voor een consistent project.

Conclusie SOAP vs REST

Uit bovenstaande onderzoek blijkt duidelijk dat SOAP de voorkeur geniet boven REST voor mijn project. Belangrijk voorbehoud hierbij is wel dat er een recent SOAP framework wordt gebruikt om de hiervoor genoemde punten te realiseren.

SOAP Java Framework keuze

Voor de selectie van een SOAP Java framework voor mijn project, zijn de volgende eigenschappen belangrijk:

• JAX-WS compliant (dit is De JEE standaard)
• Ondersteuning voor StaX parsing
• Ondersteuning voor REST.
• Code generatie voor clients.
• Bruikbaar binnen een web applicatie server (Tomcat).
• Ondersteuning voor het Spring Framework.

De bekendste SOAP frameworks met een grote community base zijn:

• Apache Axis 1 (http://ws.apache.org/axis/)
• Apache Axis 2 (http://ws.apache.org/axis2/)
• XFire/CFX (http://xfire.codehaus.org/ http://cwiki.apache.org/CXF/index.html)
• JAX-WS implementaties (Moeten geïmplementeerd zijn in een JEE 5 applicatieserver zoals JBoss). (https://jax-ws.dev.java.net).

Vergelijking van ondersteuning SOAP en REST frameworks

Voor mijn project is uiteindelijk gekozen voor het XFire/CFX framework aangezien deze aan alle eisen voldeed en met name uitblonk in de uitstekende integratie met het Spring-framework en het gemak van gebruik.

—————————————————————————————
Meer weten over Java-specialist Finalist IT Group?