SOAP en REST wanneer wat?

[fjux]

Beste mede Tweakers,

Zoals de titel al suggereert heb ik een vraag over SOAP en REST.

Maar eerste een kleine inleiding waarom ik de vraag stel.

Bij ons in het bedrijf zijn ze nu bezig met een geheel nieuwe client server applicatie opzetten, en daarnaast nog een web omgeving om de clients te managen.

En op dit moment zitten we heerlijk midden in de discussie, SOAP of REST. een paar van onze "oud gediende" is vol voor SOAP, en de jongere programmeurs zijn vol voor REST.

Het idee van dit topic is niet voor mij om een definitieve keuze te maken, maar meer om wat real-world ervaringen te krijgen/horen.

Om bedrijfsredenen ga ik niet te diep in op de echte communicatie/apparaten.

Wij hebben Apparaten die die bij klanten staan, en die communiceren allemaal met 1(of meerdere) server.
Deze server heeft vervolgens ook weer een web interface.
Alle informatie wordt via services ontvangen/verstuurd.

Tot nu toe is er voor de snelheid van het project REST gebruikt, maar hier zijn we dus nu opnieuw naar aan het kijken.

Het idee is dat onze services de communicatie opvangen van en naar de apparaten zelf, en ook naar de web frontend (deze draait op een andere server).

Nu kom ik met het zoeken veeeeeel meer tegen over hoe geweldig REST wel niet is, en dat soap verleden tijd is etc. Maar ook een paar goede verhalen over SOAP.

pro soap: https://www.ibm.com/devel...ices_rest_vs_soap?lang=en
pro REST: http://spf13.com/post/soap-vs-rest

De enige echt betere punten die ik kon vinden van SOAP zijn:
- WSDL
- WS-security

Voordelen van REST:
- Sneller
- Makkelijker
- Minder data

En nu ik zag dat de web seminar van tweakers zich ook volledig richt was ik benieuwd of SOAP echt dood aan het gaan is, of dat er nog echt een groot voordeel aan is.

Op het moment is namelijk de middenweg, deels REST en deels SOAP. Maar daar is gelijk de discussie weer mee gestart: waar dan REST en waar dan SOAP.....

Dus hoe zijn jullie ervaringen hierin/ hebben jullie mooie documenten om me nog wat verder in te lezen?

[Tsurany]

Grote voordeel van SOAP is dat het niet gebonden is aan HTTP als transport en beter om kan gaan met exactly once berichten. Een ander voordeel is dat er een duidelijk contract ligt. De aanroepende partij kan daarmee al direct valideren of de berichten die ze sturen ook correct zijn. Zeker als je werkt met enorm veel diverse (complexe) services die enkel intern gebruikt worden is SOAP handig. WSDL inladen en je kan eenvoudig je verzoeken opbouwen en controleren of je berichten valide zijn zonder dat je de andere partij nodig hebt.

Echter ga je met veel eenvoudige berichten werken kan REST een stuk makkelijker zijn. Je hoeft geen XML te gebruiken waardoor je geen heel request bericht op hoeft te stellen. Javascript met REST is een stuk eenvoudiger dan wanneer je SOAP zou gebruiken.

Maar beiden zijn in principe prima om te gebruiken, REST zou de voorkeur hebben als het gaat om een API waarvan je niet weet wie hem gaat gebruiken maar als het gaat om interne services zou het niet echt uit moeten maken welke standaard je gebruikt, als je maar goed weet wat de voor- en nadelen zijn.

In mijn huidige project werken we puur met SOAP over JMS. We werken met veel complexe data en dan is het ideaal als je per service een duidelijk gestructureerde WSDL hebt. Zeker als je tientallen services aan elkaar knoopt via tooling die mapping tussen services zeer eenvoudig maakt via een GUI.

Dus kijk goed naar je programmeertaal, de data complexiteit en de features die je nodig hebt.

[jbdeiman]

Ik vind het grote voordeel van Soap inderdaad het werken met WSDL, waardoor een te koppelen partij eenvoudig aan kan sluiten bij de Soap interface. Zeker als je (zoals Tsurany al noemt) met complexe data/ datastructuren werkt, is Soap wel de weg om te bewandelen.

Werk je met heel veel kleine beetjes, relatief eenvoudige data dan zou ik voor Rest gaan. Echter:
Omdat Rest goed gecached kan worden zou ik dat gebruiken voor de weergave van data op de web-frontend. Dit omdat dit waarschijnlijk in 1 keer om meer data gaat dan wat per apparaat heen en weer wordt gezonden. Json is voor Rest een optie en parsed sneller dan XML (de enige optie bij Soap).

Voor het heen en weer sturen van data van / naar je apparaten, tjah het is op zich om het even in het geval van een relatief simpele set aan data, maar het is vooral van belang:
- Gaat het om gevoelige data? Hoe belangrijk is de veiligheid?
- zit je vast aan het HTTP protocol, of heeft een ander protocol de voorkeur?
- Hoe ingewikkeld (en veel) is de data(structuur) welke je wil versturen?

[xleeuwx]

De reden dat veel programmeurs de weg van REST bewandelen is dat het relatief makkelijker te begrijpen is omdat het logischer in elkaar steekt. Wanneer de logica moeilijker wordt bij REST dan komt voor velen SOAP om de hoek kijken.

Echter maakt het niet uit in mijn ogen welk protocol gebruikt wordt zolang de documentatie duidelijk is en de structuur van de web service netjes is zijn voor mij beide methodes even goed.

Mijn voorkeur gaat echter naar REST vanwege de flexibiliteit en het is iets sneller.

[fjux]

Bedankt voor de reacties,

komt er in ieder geval op neer dat SOAP echt niet zo dood is als het halve internet je wilt laten geloven.

Ik denk dat bij ons het probleem ligt op het niveau, wat is ingewikkelde data en wat niet.
Voor de machine naar de web hebben we een duidelijke keuze te maken: Data security VS data verkeer. maar dat is een mooie call voor een laag hoger.

naar de frontend is op dit moment lastiger.

Deels is de frontend simpel weg data weergeven.
Maar ook de complete management van de apparaten zit hier in, en dat is weer een stuk complexer dan data weergeven.

Maar ook wordt de frontend nu ontwikkeld door een 3e partij, en willen we zorgen dat het echt een pure schil wordt voor onze services.

hebben jullie nog tips wanneer je besluit wanneer de data/actie te ingewikkeld wordt voor rest en er beter voor soap gekozen kan worden?

[ Voor 8% gewijzigd door fjux op 02-08-2016 16:35 ]

[Leftblank]

Zelf ben ik aardig te spreken over het gebruik van REST icm een specificatie volgens Swagger.io. Als je eenmaal de specificatie hebt staan kun je hiermee vrij aardige documentatie voor je API laten genereren, input valideren en door middel van Swagger codegen kun je client code laten genereren voor een aardige lijst aan programmeertalen (Java, C#, JavaScript etc) en dit is vrij eenvoudig aan te passen.

fjux schreef op dinsdag 02 augustus 2016 @ 16:34:
[..]
hebben jullie nog tips wanneer je besluit wanneer de data/actie te ingewikkeld wordt voor rest en er beter voor soap gekozen kan worden?

Uiteindelijk maakt het format van je data niet zo zeer uit lijkt mij, ongeacht of je nu XML of JSON gebruikt kun je dezelfde data omschrijven. Ik zou zelf zonder meer voor SOAP kiezen wanneer je in een scenario zit als wat Tsurany beschrijft; als je al met SOAP en of XML aan de gang gaat is het wellicht wel zo makkelijk om op die manier verder te gaan. Wil je je API (deels) kunnen gebruiken vanuit een browser dan is de keuze voor REST zo gemaakt. Alles daartussen kun je, wat mij betreft, op beide manieren oplossen.

[fjux]

dat Swagger ziet er zeker erg mooi uit!

Helaas is het alleen voor REST voor zo ver ik kan zien.

Maar inderdaad voor zowel REST als voor SOAP staat goede documentatie op prio 1.

Mogelijk kan bij de frontend soap toch beter zijn omdat de client kant de request helemaal op ieder pagina kan afstemmen. (overzicht type x met data van y) etc. ook de security ben ik bij SOAP wel over te spreken. maar REST met HTTPS is volgens mij ook veilig.

[BCC]

Oh en als je toch naar rest kijkt, kijk dan ook even naar Hypermedia. Daarmee heb ik in de praktijkhet afgelopen jaar zeer veel tijdsbesparing mee gerealiseerd. Zeker als het gaat om interactieve frontends. Maar zoals met alles geldt: het werkt goed, als je het goed toepast

[ Voor 14% gewijzigd door BCC op 02-08-2016 18:00 ]

[xleeuwx]

fjux schreef op dinsdag 02 augustus 2016 @ 17:04:
dat Swagger ziet er zeker erg mooi uit!

Helaas is het alleen voor REST voor zo ver ik kan zien.

Maar inderdaad voor zowel REST als voor SOAP staat goede documentatie op prio 1.

Mogelijk kan bij de frontend soap toch beter zijn omdat de client kant de request helemaal op ieder pagina kan afstemmen. (overzicht type x met data van y) etc. ook de security ben ik bij SOAP wel over te spreken. maar REST met HTTPS is volgens mij ook veilig.

Er ie geen reden naast performance en flexibiliteit om voor REST of SOAP te kiezen.

REST is iets sneller maar heeft meer AUTH overhead (indien je meerdere calls hebt)

SOAP is iets robuuster.

Maar kwa security / auth / encrypty ontlopen ze elkaar niet. Zolang je het bij beide goed toepast!!!

Verder dwing je de validatie van SOAP calls iets meer af doormiddel van de WSDL echter is dit ook gevaarlijk aangezien je een WSDL ook kan spoofen en dus blijft de gouden regel "never trust user input"!

[ Voor 10% gewijzigd door xleeuwx op 02-08-2016 19:19 ]

[Cartman!]

xleeuwx schreef op dinsdag 02 augustus 2016 @ 19:16:
REST is iets sneller maar heeft meer AUTH overhead (indien je meerdere calls hebt)

Welke overhead? Waarom zou authentication anders zijn dan bij SOAP?

SOAP is iets robuuster.

Wat is er precies robuuster? Validatie?

Vraag je ieder geval goed af of wat jullie aan het maken zijn meer gaat om resources (waar REST erg sterk is) of het sturen van commando's (waar RPC/SOAP nuttiger kan zijn). Een combinatie van beiden kan natuurlijk ook.

[fjux]

Cartman! schreef op dinsdag 02 augustus 2016 @ 19:51:
Vraag je ieder geval goed af of wat jullie aan het maken zijn meer gaat om resources (waar REST erg sterk is) of het sturen van commando's (waar RPC/SOAP nuttiger kan zijn). Een combinatie van beiden kan natuurlijk ook.

ja dat is inderdaad het lastigste, vanaf de machines komen soort update commando's om acties op te slaan. maar ook het opvragen van informatie van de services.

de frontend zal deels data laten zien zijn, maar ook de hele management laag zit daar in. en daarvoor zou "theoretisch" soap weer beter zijn.

zijn er overigens ergens echt harde cijfers bekend over het verschil in data verbruik? en dan niet dat je met REST iets anders kan gebruiken dan XML. maar meer de "extra" data die ze gebruiken.

[Cartman!]

Je kunt RPC ook met json doen en als dataverbruik nog belangrijker is met msgpack of protocol buffers.

[ Voor 34% gewijzigd door Cartman! op 02-08-2016 20:09 ]

[fjux]

Cartman! schreef op dinsdag 02 augustus 2016 @ 20:08:
Je kunt RPC ook met json doen en als dataverbruik nog belangrijker is met msgpack of protocol buffers.

klopt, maar voor nu zitten we nog even vast aan de XML structuur. JSON of een ander protocol komt later misschien nog. Maar als dataverbruik een real issue wordt zijn dit wel zeer interessante oplossingen!

[djluc]

Ik zou ook zeker de beschikbare kennis meenemen in je overweging. Overschakelen met tools, denkwijze en inhoudelijke kennis is niet zomaar een eenvoudige stap. Alleen al zaken als end-to-end tests die totaal anders worden, updates van de apparatuur op locatie etc. kan een flinke slag in het budget maken.

Als je met een investering in je bestaande keuze middels bijvoorbeeld training, tools (zoals Swagger) en andere optimalisaties een verbetering kunt bereiken kan dat ook veel waard zijn. Ook kan de keuze van een manier van werken een invloed hebben op je aanbod van personeel.

Kortom: Bekijk je business case als geheel en niet alleen op techniek.

Tot nu toe is er voor de snelheid van het project REST gebruikt, maar hier zijn we dus nu opnieuw naar aan het kijken.

Wat is de aanleiding hiervoor?

Technisch gezien is dit een MS - Linux discussie. Met beide kan je prima aan de slag, super mooie oplossingen maken en efficient werken. Het is vaak een kwestie van voorkeur. Daarom is het belangrijk in dit soort discussies om het meer vanuit het oogpunt van resultaat voor de klant/bedrijf te bekijken dan puur in technische zin.

SOAP is zeker niet dood, zeer goed geïntegreerd in veel professionele software platforms en zal echt niet ineens verdwijnen. REST klinkt meer modern, is bij meer developers bekend die de SOAP software niet meegemaakt hebben en wordt veel gebruikt voor nieuwe applicaties. Daarom vind je daar veel meer over. Maar als je kijkt naar hoe het gebruikt wordt in de praktijk is er vaak nog veel op aan te merken.

Als je dieper wilt gaan qua kennis is het interessant om wat meer over de achtergrond en de denkwijze van de bedenker te weten: Roy Fielding. Wikipedia: Roy Fielding en zijn blog: http://roy.gbiv.com/untan...-must-be-hypertext-driven (lees de discussie in de comments). Vaak worden api's REST genoemd terwijl ze dit absoluut niet zijn. Voor SOAP is het wat minder een specifiek persoon of blog, er zijn meer grote organisaties, zoals IBM maar ook Microsoft, die achter deze standaard staan en er in geïnvesteerd hebben. Maar nogmaals, technisch zijn beide prima in vrijwel alle gevallen.

[raptorix]

SOAP is vooral een enorm voordeel als je met andere partijen moet samenwerken, op die manier kan er geen discussie ontstaan of de implementatie fout is, of dat de serverende partij het fout doet.

Overigens is een combinatie van SOAP en rest natuurlijk ook mogelijk.

Wat natuurlijk ook enorm producatief is is dat je op basis van een WDSL redelijk snel al je methodes tot je beschikking heb in je code.

Een nadeel van SOAP is dat als de WDSL vaak wijzigt je redelijk goede afspraken moet gaan maken met de implementerende partij.

[Lethalis]

raptorix schreef op woensdag 03 augustus 2016 @ 11:11:
Een nadeel van SOAP is dat als de WDSL vaak wijzigt je redelijk goede afspraken moet gaan maken met de implementerende partij.

Als de WSDL vaak wijzigt, doe je iets verkeerd

Ik erger me altijd dood als een leverancier zomaar beslist zijn hele API te verbouwen zonder dat daar een absolute noodzaak voor was.

Daarom moet je een API ook altijd zo opbouwen dat hij makkelijk uit te breiden is.

Closed for modification, open for extension

PS:
Ik gebruik tegenwoordig steeds vaker REST ipv SOAP. De hoofdreden hiervoor is eigenlijk gemak. Het is veel eenvoudiger om een REST API te implementeren en te consumeren.

[Gomez12]

Waarom überhaupt kiezen? Momenteel ben ik in .net een service laag aan het maken die gewoon en via Rest en via Soap aan te spreken is zonder navenant veel extra code (SOAP vereist welgeteld een paar interfaces extra boven pure Rest, maar die heb ik toch al).

In .net gebruik ik de web api 2.0 aangevuld met een automatisch gegenereerde swagger documentatie en daarnaast nog de standaard wsdl. Dus ik heb gewoon 3 standaard gegeneerde documentaties (naast de handgeschreven die er ook nog moet komen).

Ik vermoed dat mijn situatie wel iets anders is, omdat externe devvers tegen onze service laag aan moeten praten en we weten dat dat varieert van JS op een website om een plaatje op te halen naar complete SAP-implementaties die veelal weer liever SOAP hebben.
Onze eerste gedachte was ook : We gaan het scheiden naar SOAP-services en REST-services, alleen waar dan die scheidslijn kwam werd compleet ondoorzichtig. Toen zijn we maar eens gaan kijken naar hoeveel moeite het zou kosten om het gewoon alletwee standaard te implementeren en dat was uiteindelijk verassend weinig extra werk.

Huidige situatie is dan ook dat je kan zeggen dat SOAP overkill is voor sommige services omdat die gewoon supersimpel zijn in REST, maar omgekeerd hebben we ook services waarbij ik me vanwege de verplichte velden afvraag of je het überhaupt ooit eens in een REST gaat krijgen.

[raptorix]

Lethalis schreef op woensdag 03 augustus 2016 @ 13:46:
[...]

Als de WSDL vaak wijzigt, doe je iets verkeerd

Ik erger me altijd dood als een leverancier zomaar beslist zijn hele API te verbouwen zonder dat daar een absolute noodzaak voor was.

Daarom moet je een API ook altijd zo opbouwen dat hij makkelijk uit te breiden is.

Closed for modification, open for extension

PS:
Ik gebruik tegenwoordig steeds vaker REST ipv SOAP. De hoofdreden hiervoor is eigenlijk gemak. Het is veel eenvoudiger om een REST API te implementeren en te consumeren.

Mee eens, enige tijd terug hadden we daar wel een uitdaging, we hadden daar Salesforce als CRM ingericht, dat moest gekoppeld worden met de website, nu gaat dat koppelen best aardig omdat je vanuit Salesforce met 1 klik de WDSL kunt downloaden, echter het Salesforce stuk werd door een ander team ontwikkeld, kortom hier moet je wel rekening mee houden

[_Erikje_]

De REST variant van de de WSDL is de WADL. Kijk daar ook naar.

[fjux]

Het idee is natuurlijk om nu dus voor ons ook om een basis standaard neer te zetten, en deze zo nodig later uit te breiden met extra functionaliteiten.

Ik denk dat nu bij ons de beslissing er vooral op neer moet komen hoe we de web omgeving gaan vormgeven.

Gaat het echt een andere webserver worden die de data gaat opvragen bij onze services dan is SOAP waarschijnlijk beter.

Maar als het helemaal client side gaat worden (html + javascript) dan is waarschijnlijk rest weer beter.
maar ben ook al weer implementaties van SOAP in javascript tegen gekomen, maar geen flauw idee of dat ook echt lekker gaat werken of niet. http://javascriptsoapclient.codeplex.com/

[ Voor 0% gewijzigd door fjux op 11-08-2016 17:21 . Reden: typo ]

[johnkeates]

Ik zou geen SOAP meer doen. REST is geen slechte keuze, maar msgpack of een echte 'bus' zou ook geen slecht idee zijn. Client-Server software laten communiceren hoeft helemaal niet perse over HTTP te gaan, en XML is ook helemaal niet altijd de beste keuze.

JSONP of msgpack zijn prima te gebruiken, en queue's kunnen ook prima in Client-Server situaties ingezet worden, het is dan net alsof je gratis load balancing en redundancy er bij krijgt. Ondoorzichtige zaken zoals DCERPC of named pipes over een netwerk zou ik dan weer mijden om dat ze niet erg cross-platform zijn, en je vrij snel binden aan 1 toolchain of 1 omgeving.

[Hydra]

http://harmful.cat-v.org/software/xml/soap/simple

Dat gezegd: ik zie in mijn werk eigenlijk bij nieuwe services nooit meer SOAP langskomen. Het werkt 'op zich' best okay (mits de service contract-first opget is, een WSDL genereren uit code levert vrijwel altijd bagger op) maar er zitten een hoop zaken in de standaard die slecht/niet gesupport worden. REST is veel simpeler: je maakt gewoon afspraken waar beide partijen zich aan houden; je hebt maar 1 set afspraken. In veel gevallen was het zo dat je bij SOAP services 2 sets afspraken had: wat in de spec stond en wat er daadwerkelijk verstuurd werd (lang leve XSD:Any).

Komt nog eens bij dat moderne frameworks (zelf gebruikt ik Spring Boot zowel in eigen projecten als op werk) het maken van een REST service extreem simpel maken. Het (de)serialiseren en het genereren van swagger documentatie wordt praktisch helemaal voor je gedaan.

[Tsurany]

SOAP werkt voornamelijk prima in combinatie met tooling. Bijvoorbeeld BPM/SOA applicaties waarbij je niet meer zelf programmeert maar eerder configureert. Dan is een WSDL in een minuutje gemaakt, volledig conform specs en kan iemand anders die WSDL inladen (copy/paste) en direct zien hoe een interface er uit ziet en welke data heen en weer gaat.
Als je fatsoenlijke XSD's maakt dan heb je daar echt geen problemen mee.

[Hydra]

Tsurany schreef op vrijdag 12 augustus 2016 @ 11:49:
Als je fatsoenlijke XSD's maakt dan heb je daar echt geen problemen mee.

Dat is het probleem dus. Je moet een WSDL (inclusief XSDs) 'met de hand' maken en goed kijken of het correcte code oplevert. Veel devs / bedrijven doen dat niet en gebruiken brakke tools om het te genereren. Dat of de input/output messages bevatten gewoon een XSD:Any waarin dan een (vaak slecht gedocumenteerde) XML structuur heen en weer gestuurd wordt.

Veel bedrijven die op MS spullen werken gebruikten bijvoorbeeld de in VS aanwezige functionaliteit die niet conformerende WSDLs opleverden. Dan had je dus een Asp.net webservice die alleen te lezen is door andere .net clients.

SOAP is leuk in theory maar in de jaren gewoon uitgegroeid tot een mislukte standaard die door veel verschillende vendors slecht en halfbakken geimplementeerd is. Als dat het geval is, is de stap naar zelf gewoon XML berichten heen en weer sturen een stuk simpeler. En dan is JSON in plaats van XML een logische vervolgstap.

SOAP was een stap vooruit t.o.v. binaire protocollen over TCP/IP. Maar in de praktijk was het te convoluted, waren er te veel sub-specificaties en waren de vendors nogal geneigd hun eigen interpretatie te pushen als 'de standaard'. Ik heb in mijn tijd veel SOAP gebaseerde webservices gemaakt (allemaal contract first m.b.v. Axis2) maar bij het maken van clients liep ik altijd tegen bagger van anderen aan.

[Tsurany]

SOAP is inderdaad niet handig als je waardeloze ontwikkelaars hebt die niet goed met standaarden om kunnen gaan. Echter met fatsoenlijke software en fatsoenlijke ontwikkelaars heb je al die nadelen gewoon niet.

[Hydra]

fjux schreef op dinsdag 02 augustus 2016 @ 15:15:
pro soap: https://www.ibm.com/devel...ices_rest_vs_soap?lang=en

Heb je de datum daar gezien? Ik zou niet te veel waarde hechten aan een meer dan 10 jaar oude blogpost. Ik ben ergens rond die tijd op een webservices conferentie in Zweden geweest en was toen ook erg lovend over webservices gewoon omdat het alternatief, binaire RPC over TCP/IP, gewoon slechter was. Probeer dat maar eens te debuggen!

SOAP is gewoon op sterven na dood. Het wordt eigenlijk alleen nog gebruikt in antieke service-bus architecturen die niet goed met REST overweg kunnen (ondersteunen alleen XML en/of alleen HTTP POST bijvoorbeeld). Ik werk zelf op dit moment bij de ING als externe Java dev en zelfs in bankenland is men helemaal over op JSON en alle nieuwe API's moeten aan een REST specificatie voldoen (de mobiele back-end is wel JSON maar niet echt REST, dit zijn ze aan het migreren).

SOAP was een verbetering t.o.v. er voor kwam. De hedendaagse REST best practices zijn daar weer een verdere ontwikkeling op. Het werkt makkelijker en sneller voor alle betrokken developers, zowel aan de bouw kant als aan de consumeren kant.

Wat ik bij de ING zie in het SOAP kamp zijn, zoals gewoonlijk, de ouwe lullen die geen nieuwe dingen willen leren.

Tsurany schreef op vrijdag 12 augustus 2016 @ 12:52:
SOAP is inderdaad niet handig als je waardeloze ontwikkelaars hebt die niet goed met standaarden om kunnen gaan. Echter met fatsoenlijke software en fatsoenlijke ontwikkelaars heb je al die nadelen gewoon niet.

Dat zal best, in theorie, maar in de praktijk zijn er eigenlijk bar weinig 'fatsoenlijke' ontwikkelaars als je die definitie aanhoudt.

Daarnaast zijn de voordelen van SOAP vooral theoretisch. In de praktijk heb je het voornaamste voordeel, dat je code genereert uit een WSDL, helemaal niet nodig. Frameworks als Spring Boot laten je gewoon JSON van en naar objecten serialiseren. Een service maken is extreem simpel. En een dergelijke service is ook erg simpel te consumeren vanuit een willekeurige client; of het nu een AngularJS page is, een mobiele app of een andere service maakt geen fluit uit.

Wat ik al zei: ik heb vroeger een hoop SOAP services gemaakt. Tegenwoordig is een REST service (m.b.v. bijv. Spring Boot) veel sneller te maken, makkelijker te testen (de GETs kun je vanuit je browser doen) en makkelijker te consumeren. Ook het ondersteunen van formaten anders dan JSON is erg simpel, SOAP services ondersteunen dit AFAIK helemaal niet (buiten blobs in CDATA tags van je payload, maar dan verdien je m.i. dat je programmeer-pas ingetrokken wordt).

M.i. is er geen enkele reden om tegenwoordig nog SOAP services te bouwen.

Oh en ik had dit deel gemist:

Tsurany schreef op dinsdag 02 augustus 2016 @ 15:42:
Grote voordeel van SOAP is dat het niet gebonden is aan HTTP als transport

Da's alleen in theorie. Leuk dat je SOAP over FTP of SMTP kunt doen maar dat doet niemand en ondersteunt ook vrijwel geen enkel framework. Dit is wel typerend voor de hele discussie. WS-security is ook een mooi voorbeeld; in theory super, in de praktijk een teringzooi dus gebruikt vrijwel niemand het en legt men gewoon een VPN aan.

Cartman! schreef op dinsdag 02 augustus 2016 @ 20:08:
Je kunt RPC ook met json doen en als dataverbruik nog belangrijker is met msgpack of protocol buffers.

Yup. En hedendaagse frameworks ondersteunen het switchen op basis van accept headers of file extensies ook prima. Je REST service kan best tegelijkertijd JSON, XML, Smile en Protobuf ondersteunen als je dat wil. probeer dat maar eens met een webservice.

[ Voor 51% gewijzigd door Hydra op 12-08-2016 13:41 ]

[Tsurany]

Hydra schreef op vrijdag 12 augustus 2016 @ 13:25:
Da's alleen in theorie. Leuk dat je SOAP over FTP of SMTP kunt doen maar dat doet niemand en ondersteunt ook vrijwel geen enkel framework. Dit is wel typerend voor de hele discussie. WS-security is ook een mooi voorbeeld; in theory super, in de praktijk een teringzooi dus gebruikt vrijwel niemand het en legt men gewoon een VPN aan.

FTP of SMTP heb je natuurlijk niet veel aan maar vaak zie je nog JMS gebruikt worden hiervoor.

[Harmsen]

Hydra schreef op vrijdag 12 augustus 2016 @ 13:25:
[...]

SOAP is gewoon op sterven na dood. Het wordt eigenlijk alleen nog gebruikt in antieke service-bus architecturen die niet goed met REST overweg kunnen (ondersteunen alleen XML en/of alleen HTTP POST bijvoorbeeld). Ik werk zelf op dit moment bij de ING als externe Java dev en zelfs in bankenland is men helemaal over op JSON en alle nieuwe API's moeten aan een REST specificatie voldoen (de mobiele back-end is wel JSON maar niet echt REST, dit zijn ze aan het migreren).

Service bus architecturen gaan ook met de tijd mee hoor

Ik werk binnen mijn werkgever in het team dat verantwoordelijk is voor de meeste datastromen tussen applicaties binnen het bedrijf, maar ook naar externe partijen. Dit doen we via Microsoft software (BizTalk) samen met zelfgebouwde add-ons. Wij proberen zo flexibel mogelijk te zijn als team qua protocollen/technieken/data vormen. Op dit moment communiceren we via SOAP, HTTP (al dan niet REST), AS2, AS4, (S-)FTP(S), FIX, SQL, Email, SQL koppelingen of files

Als een externe partij voor een service bijvoorbeeld REST gebruikt en de interne applicatie die die service nodig heeft geen REST ondersteund dan zorgen wij als team voor de transformaties. Ook XML <-> JSON transformaties is geen probleem. Een interne applicatie gaat vanwege budget redenen niet zomaar aangepast worden om ook REST te gaan ondersteunen, vooral niet de wat oudere legacy applicaties.

Voor jouw vraag of je nu voor REST of SOAP moet kiezen hangt ook van de context van de nieuwe applicatie af: Bouw je zelf de clients en de service? Of moeten ook 'antieke service bussen' gebruik kunnen gaan maken van de service? Wil je dat zoveel mogelijk clients gebruik kunnen van je service zorg er dan voor dat je zowel SOAP als REST aanbied.

Persoonlijk zou ik nu voor een REST service gaan die zowel JSON als XML data kan gebruiken. Ik merk dat REST met JSON telkens meer gebruikt wordt binnen services en het is altijd leuk om nieuwere dingen te gebruiken.

Maar wat je ook kiest: Zorg ervoor dat je afspraken en documentatie van de services duidelijk zijn! Een goede WSDL of Swagger kan je hiermee enorm helpen.

[fjux]

Wow, bedankt voor de enorm goede feedback!

we hebben nu het voordeel dat we een complete revisie van ons gehele software pakket maken.

Wat inhoud dat we volledige controle hebben over alle schakels in het systeem.
Het is niet zo zeer dat er op dit moment ook andere bedrijven direct aan ons systeem gekoppeld gaat worden, dus we kunnen alles kiezen wat we willen.

even nog een extra vraagje:
Vaak komt Swagger voorbij en nu ook spring.io

kloppen deze aannames?

spring.io is een library voor java om het ontwikkelen van rest gemakkelijker te maken

swagger.io is een tool om afspraken voor de interface vast te leggen (als een WSDL)

Als dat zo is, een paar vragen over beide:

Spring.io, zijn er alternatieven/bewezen dat het stabiel werkt?

Swagger: is dit een offline tool of online? kan het niet echt lekker vinden.
En die code gen, is dat aan te raden, of is het beter om swagger te gebruiken voor de afspraken, en het vervolgens zelf te bouwen?

[Caelorum]

Swagger is een specificatie, geen tool. Er is wel tooling beschikbaar om deze te consumen.
VS2015 Update 3 kan standaard een .NET REST client genereren aan de hand van een swagger specificatie-bestand. Voor .NET WebAPI is er bijv. een package (Swashbuckle) die dynamisch een UI incl. specificatie kan genereren.

Voor java is er hun eigen tooling en voor andere platformen/talen is er vast ook wel dergelijke tooling beschikbaar.

[ Voor 3% gewijzigd door Caelorum op 12-08-2016 15:05 ]

[Tsurany]

De beste reden om voor REST te kiezen is om Swagger certified te kunnen zijn.

[fjux]

Caelorum schreef op vrijdag 12 augustus 2016 @ 15:05:
Swagger is een specificatie, geen tool. Er is wel tooling beschikbaar om deze te consumen.
VS2015 Update 3 kan standaard een .NET REST client genereren aan de hand van een swagger specificatie-bestand. Voor .NET WebAPI is er bijv. een package (Swashbuckle) die dynamisch een UI incl. specificatie kan genereren.

Voor java is er hun eigen tooling en voor andere platformen/talen is er vast ook wel dergelijke tooling beschikbaar.

Wij gebruiken java, Maar automatisch gegenereerde code ben ik nooit zo 100% zeker van.
Maarja als het gewoon werkt, waarom niet

ik zie nu dat het inderdaad gewoon een offline tool is (of op je eigen webserver kan draaien)
ziet er wel goed uit zeg! duidelijker dan wat voor een documentatie/WSDL dan ook.

[CH4OS]

fjux schreef op vrijdag 12 augustus 2016 @ 15:10:
Wij gebruiken java, Maar automatisch gegenereerde code ben ik nooit zo 100% zeker van.

Offtopic, maar daar zijn o.a. unittests voor.

[fjux]

CH40S schreef op vrijdag 12 augustus 2016 @ 16:02:
[...]
Offtopic, maar daar zijn o.a. unittests voor.

Fair point, maar krijgen we dan automatische gegenereerde unittests voor automatisch gegenereerde code?

Maar inderdaad, als we de interface laten genereren en dan zelf unittests schrijven is er niets aan de hand

Maar ontopic:

De reacties tot nu toe neigen eigenlijk voor alle nieuwe systemen op REST. Niet dat SOAP gelijk een slechte keuze is, maar REST gewoon makkelijker.

SOAP naar andere/oudere systemen is vaak wel weer handig.
wat in mijn optiek ook prima naast elkaar kan draaien.

[CH4OS]

Je kunt ook altijd nog een combinatie maken, lijkt me?

[Creepy]

Hier gebruiken we swagger zonder dat we het code laten genereren, puur voor de online/live documentatie tool. Gewoon Jersey gebruiken voor de REST interface met wat Swagger annotaties zodat Swagger ook z'n werk kan doen. Ja, je kan Swagger een client laten genereren, maar dat is echt niet nodig. Met de online docs/client die Swagger standaard oplevert heb je zowel een beschrijving van je API, als een werkende voorbeeld client beschikbaar via de browser, wat wat mij betreft een aantal nadelen t.o.v. SOAP weer opheft.

Maar als je al REST gebruikt en dat werkt, dan zie geen reden om zomaar over te stappen op SOAP.

[Hydra]

Caelorum schreef op vrijdag 12 augustus 2016 @ 15:05:
Swagger is een specificatie, geen tool. Er is wel tooling beschikbaar om deze te consumen.
VS2015 Update 3 kan standaard een .NET REST client genereren aan de hand van een swagger specificatie-bestand. Voor .NET WebAPI is er bijv. een package (Swashbuckle) die dynamisch een UI incl. specificatie kan genereren.

Voor java is er hun eigen tooling en voor andere platformen/talen is er vast ook wel dergelijke tooling beschikbaar.

Je hebt tooling om Swagger documentatie uit je code te genereren. Beetje zoals je met JavaDoc documentatie genereert. Vanuit Swagger een Spring REST service genereren doet niemand (als het al mogelijk zou zijn).

fjux schreef op vrijdag 12 augustus 2016 @ 14:57:
spring.io is een library voor java om het ontwikkelen van rest gemakkelijker te maken

Dat is nogal kort door de bocht. Ik vind het wel bijzonder dat jullie "Java gebruiken" maar je niet weet wat Spring is.

Spring is een library van libraries. Spring JPA gebruik je voor DB access, Spring MVC voor REST e.d., Spring Security voor Security. Het meest gebruikte component is het dependency injection component. Spring is te vergelijken met Java EE. Het is ook een stuk populairder dan JEE.

swagger.io is een tool om afspraken voor de interface vast te leggen (als een WSDL)

Het is als JavaDoc maar dan voor REST interfaces. Je kunt (als je wil) vanuit Swagger doc ook clients genereren maar het is vooral bedoeld als documentatie. Er zijn verschillende plugins beschikbaar om Swagger docs (a la JavaDoc) te genereren maar je kan het ook met de hand doen.

Spring.io, zijn er alternatieven/bewezen dat het stabiel werkt?

Euhm. Het is een beetje de defacto standaard in Java land?

Swagger: is dit een offline tool of online? kan het niet echt lekker vinden.
En die code gen, is dat aan te raden, of is het beter om swagger te gebruiken voor de afspraken, en het vervolgens zelf te bouwen?

Voor een service is het niet echt bruikbaar als codegen tool. Het is ook niet nodig; de controller laag is over het algemeen erg simpel.

Harmsen schreef op vrijdag 12 augustus 2016 @ 14:28:
Service bus architecturen gaan ook met de tijd mee hoor

Mijn ervaring met "service bus" mensen is dat die een beetje een andere definitie hebben van "met de tijd meegaan". Tibco clubjes binnen ING die SOAP blijven pushen omdat dat "sneller ontwikkelt" dan REST. In de trant van "SOAP is in 2 weken klaar, REST in 6". Dus ik ben blij voor je dat jij in een groep mensen zit die wel up to date is

[ Voor 59% gewijzigd door Hydra op 13-08-2016 09:55 ]

[Caelorum]

Hydra schreef op zaterdag 13 augustus 2016 @ 09:47:
[...]
Het is als JavaDoc maar dan voor REST interfaces. Je kunt (als je wil) vanuit Swagger doc ook clients genereren maar het is vooral bedoeld als documentatie.[...]

De specificatie heeft nou net als doel om ook machine readable te zijn zodat je juist consumers kan genereren aan de hand van de specificatie.

[Hydra]

Caelorum schreef op zaterdag 13 augustus 2016 @ 10:37:
De specificatie heeft nou net als doel om ook machine readable te zijn zodat je juist consumers kan genereren aan de hand van de specificatie.

Dat is een doel, niet het doel. Je kunt een client generen (of een mock service) maar het levert je niet echt winst op. Het (de)serialiseren van JSON is gewoon te triviaal. Dit itt een SOAP client; daar komt een stuk meer bij kijken (kijk voor de gein eens wat WSDL2Java uitspuugt).

Hoewel het mogelijk is zou ik vanuit Swagger hoogstens een tijdelijke mock service genereren.

[Caelorum]

Hydra schreef op zaterdag 13 augustus 2016 @ 11:26:
[...]
Dat is een doel, niet het doel.[...]

Het is inderdaad een doel. Het doel is ene specificatie zijn dat onder andere machine readable is. Waarom zou je de moeite doen een machine readable specificatie te genereren/maken als je het niet gaat gebruiken?

[...] Je kunt een client generen (of een mock service) maar het levert je niet echt winst op. Het (de)serialiseren van JSON is gewoon te triviaal. [...] Hoewel het mogelijk is zou ik vanuit Swagger hoogstens een tijdelijke mock service genereren.

Waarom met de hand een client genereren als dit ook automatisch kan? En triviaal is ook niet alles. Als jij 40 verschillende objecttypes hebt die allemaal in een REST service zijn exposed heb je toch echt wel wat werk. Dan kan je die eerste stap net zo goed laten genereren.

[Hydra]

Caelorum schreef op zaterdag 13 augustus 2016 @ 12:36:
Waarom met de hand een client genereren als dit ook automatisch kan?

Op werk hebben we een microservice architectuur waar veel services clients zijn van andere services. We gebruiken gewoon een spring rest-template die de mapping voor ons doet. Het heeft voor ons nul zin een client uit te genereren gewoon omdat een JSON blob naar een object mappen letterlijk 1 regel code is.

Misschien is dit compleet anders als je bijvoorbeeld PHP ofzo gebruikt maar het levert ons gewoon geen snelheidwinst op. We gebruiken een Spring MVC swagger plugin die de Swagger documentatie voor ons genereert.

[Caelorum]

Hydra schreef op zaterdag 13 augustus 2016 @ 14:06:
[...] Het heeft voor ons nul zin een client uit te genereren gewoon omdat een JSON blob naar een object mappen letterlijk 1 regel code is. [...]

Je moet dan alleen dat object nog definieren, maar ik snap je punt.