bloghoved rene løhde

Web Service er død - REST in peace! (2:3)

På John Gøtzes gamle blog kan man se at han har læst en bog ' RESTful webservices. Jeg læste Johns anmeldelse af bogen i den trykte Version2 (jeg kan ikke finde den artikel online, men den kommer vel' Vibeke') ' den var god, oplysenden og giver en introduktion til hvad REST er.

Mit REST 'elevator pitch' er: REST er en arkitekturstil brugt i forbindelse med udarbejdelsen at webapplikationer ' det kan f.eks være en webklient eller en webservice. Arkitekturen bruger gængse web faciliteter til at arbejde med ressourcer identificeret ved URL'er. En statisk HTML side er et eksempel på en simpel 'REST webservice' ' man kan tilgå den via HTTP GET og den er 'placeret på' og identificeret via en URL. Hvis man har de fornødne akkreditiver vil man også kunne lave andre operationer på den resource som HTML siden er ' f.eks HTTP PUT for opdatering eller HTTP DELETE for sletning.

De fleste IT folk vil formenlig sige 'okay, REST er bare URI adresser med ressourcer, som kan bearbejdes via HTTP metoder ' dvs nøjagtig lige som alt andet på WWW?. Og ja, det er netop så simpelt, og nok derfor succesfuldt!

Nu har jeg så også læst bogen ' bare så jeg også kan tale med om den seneste udvikling nede på Ørsted Ølbar og Cafe ud på de små timer. Når det er sagt ' så var der også 4 andre grunde til at læse bogen:

  1. Bogen kan være det bedste bud på en formaliseret semantik omkring REST webservices og som 'IT ARKITEKT' er jeg selvfølgelig nød til at kende semantikken når folk begynder at snakke om 'RESTful webservices' og 'REST-RPC Hybrids' ? specielt når mit primære fagdomæne er webservices.

  2. En af standarderne i SOAP land ' WSDL - har lige fået REST support (eller kan nu angive metadata for REST baserede servies) og hvad betyder det egentlig' [Det må jeg nok hellere finde ud af og fortælle om erfaringerne i en anden post]

  3. Min hæderkronede helt, guru og SOAP halvfader, Don Box, er faldet til REST-patten, hvilket med andre ord betyder, at mit elskede WCF får en ny httpBinding i .Net 3.5, som har REST support for udstilling af webservices.  NB! Jeg har faktisk noteret mig at SOAP, fra at have mistet sin akronymstatus nu har genvundet den. Originalt var det Simple Object Access Protocol, men det var ikke simpelt, man tilgik ikke nogle objekter og det var ikke rigtigt en protokol. Derefter blev det SOAP ' bare SOAP og nu (stadig kun uofficielt :-)) Simple Object Apology Protocol ?Jeg er ikke enig i alt der står i den blogpost, men den giver et meget godt grundlag for videre debat.

  4. Jeg var nysgerrig efter at se hvordan man fra en i REST arkitektur implementerer 3 helt specifikke egenskaber ? konfidentiel, uafviselighed og pålidelighed. Egenskaber, som kan implementeres via WS-*-stakken

Mit forhold til REST går langt tilbage og er ikke nødvendigvis noget nært forhold f.eks når jeg har evangeliseret SOAP WebServices og en-eller-anden 'ignorant' efter min lange SOAP udredning med kodeeksempler og deslige, stiller spørgsmålet ' kan jeg ikke bare hente det XML dokument via HTTP GET' ...og svaret er et forkvaklet 'Jooohhh!' ....og når jeg så sundet mig lidt så kommer jeg med det, som jeg altid har spekuleret over i forhold til REST:

Hvordan implementerer jeg konfidentialitet, uafviselighed og pålidelighed (de 3 foretningskrav fra punkt 4 ovenfor) ved hjælp at HTTP metoder og de teknologier traditionel web teknologi stiller til rådighed ' og specielt hvis det er end-2-end scenarie og med routening via minimum en 'hub''

Det er 3 fuldt valide forretningskrav, som blandt andet er stillet i forbindelse med Globaliseringsrådets oplæg til ehandelsinfrastruktur.
De tre krav kan honoreres i WS-* stakken ved hjælp at WS-Security og WS-ReliableMessagning, men hvad med REST' Gav bogen mig svar på mine spørgsmål' ? ja, det gjorde den faktisk (sort of!):

For konfidentielt og uafviselighed:

'Suffice it to say that security concepts are much better specified and deployed in SOAP-based protocols than in native HTTP protocols ' That doesn't mean that this gap can't be closed ' Right now, though, SOAP has many security-related stickers that HTTP doesn't have, and these stickers are useful when implementing applications?  

As a caution, many of these areas are not areas where amateurs can productively dabble. Nobody should try to add new security concepts to HTTP all by themselves.?

('Restful Web Services',L. Richardson & S. Ruby, s. 311, O?Reily)

 

For pålidelighed:

 'WS-ReliableMessaging standard is motivated mainly by complex scenarios that REST-ful web services don't address at all. These might be situations where a message is routed through multiple protocols on the way to its destination''

('Restful Web Services',L. Richardson & S. Ruby, s. 312, O?Reily)

 

Hey ' så er den tid jeg har investeret i SOAP måske alligevel ikke tabt på gulvet. Der er bare endnu en gang tale om at en 'one-size-fits-all' verden ikke er hensigtsmæssig. Min SOAP kompetence har stadig en plads fordi der er scenarier hvor REST baserede service bare ikke kan levere en fornuftig løsning.  Men i 80% af tilfældene vil REST være 'nok' ' hvilket vel også understøttes af at de populærest services på nettet, er REST services. Generelt er min fornemmelse at  i HTTP, URI og XML (og nu måske i stigende grad suppleret med JSON) web scenariet, er der antalsmæssigt en klar overlegenhed i REST favør.

I sidste afsnit af mine juli REST studier vil jeg vise en service udstillet via HTTP, URI og Verbs (RESTful) og HTTP POST med konvolut (SOAP) ? og så håber jeg at du har mod på at prøve at konsumere servicen selv.     

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Schmidt

Konfidentialitet: HTTPS

Pålidelighed: TCP (jeg forstår nok ikke helt scenariet, hvor WS-RM er relevant)

Uafviselighed: S/MIME (det er snyd, idet standarden er beregnet til e-mail, men som sådan egner standarden sig vel udmærket til at blive sendt over HTTP)

  • 0
  • 0
René Løhde

Anne-Sofie,

Tak, skal du ha' - det prøver jeg næste gang!

Michael,

LOL

Christian,

Yes, du har ret med https for så vidt angår punkt til punkt - beskeden er konfidentiel under transport. I et scenarie hvor beskeden skal routes gennem en hub vil der være konfidentialitet mellem afsender og hub og mellem hub og modtager, men på hub'en vil beskeden kunne læses.

I det scenarie, som er lagt frem fra Center for Serviceorienteret Infrastruktur (CSI) til fremsendelse af ehandelsbeskeder f.eks order er "hubs" en forudsætning for at infrastrukturen kan komme i drift. F.eks hvis min virksomhed ville sende en efaktura via internettet til en offentlig myndighed. Myndighederne får i dag deres faktura på det såkaldte VANS netværk. Dvs for at få min faktura fra internettet og ind på VANS netværket skal jeg igennem minimum en hub/gateway.

Hvad angår pålidelighed - i samme eksempel som ovenfor - jeg ved ikke hvad transportprotokollen er eller hvordan VANS netværket ser ud, men det er også ligegyldigt sålænge jeg bruger WS-RM. Fordi så ligger pålideligheden i SOAP'en og dennes headers og ikke i transportprotokollen. Jeg skal så blot håbe at alle hubs forstår SOAP med WS-RM.

Angående S/MIME - en god grund til at holde ud S/MIME i arms længde her, er at S/MIME ikke tilbyder kryptering af udvalgte områder. Det er en alt eller intet tilgang. Hvis man krypterer hele beskeden hvordan kan eventuelle SOAP-aware hubs så læse WS-RM information.

  • 0
  • 0
Rasmus Kaae

Rene, jeg må nok sige at jeg blev skuffet over at læse dette blog-indlæg! Efter at have læst dit forrige omkring WebServices og REST havde jeg håbet på lidt større saglighed i indlægget.

En sidste ting er at jeg undrer mig lidt over ordvalget i indlægget. Hvorfor ikke bruge gode danske ord i stedet for f.eks. "konfidentielt" kunne man anvende et dejligt ord som "fortrolighed".

Sådanne angloficeringer er relativ irriterende at læse :)

  • 0
  • 0
Christian Schmidt

Dennis Krøger
"Enhver blok data kan signeres, og dermed være uafviselig. Der er ingen grund til at dette udelukkende skulle gælde S/MIME."
Ja, alt kan signeres, men signaturen skal jo repræsenteres på en standardiseret måde. Her er S/MIME et bud på et format. Formatet benyttes dog kun i e-mail.

  • 0
  • 0
Christian Schmidt

"I et scenarie hvor beskeden skal routes gennem en hub vil der være konfidentialitet mellem afsender og hub og mellem hub og modtager, men på hub'en vil beskeden kunne læses."
Man kan godt route en krypteret HTTPS-forbindelse uden at dekryptere den undervejs. Men det kræver så, at man allokerer en ip-nummer+port-kombination pr. modtager, hvilket nok er mindre hensigtsmæssigt.

"Hvad angår pålidelighed - i samme eksempel som ovenfor - jeg ved ikke hvad transportprotokollen er eller hvordan VANS netværket ser ud"
Snakker man i praksis andet end TCP på omtalte netværk? Eller vi taler måske om REST i en bredere forstand end HTTP over TCP? I givet fald står jeg vist af :-)

"Angående S/MIME - en god grund til at holde ud S/MIME i arms længde her, er at S/MIME ikke tilbyder kryptering af udvalgte områder. Det er en alt eller intet tilgang. Hvis man krypterer hele beskeden hvordan kan eventuelle SOAP-aware hubs så læse WS-RM information."
Evt. kan man pakke beskeden som en multipart-mail med udvalgte dele krypteret og hele molevitten signeret. Men o.k. - så er vi vist derude, hvor man opfinder sine egne standarder bare for at undgå at bruge WS-RM eller tilsvarende.

Jeg siger i øvrigt ikke, at det nødvendigvis er fornuftigt at forsøge en REST-tilgang i det tilfælde, du beskriver.

  • 0
  • 0
René Løhde

Christian,

Jeg tror dine "hacks" udemærket illustrerer hvorfor WS-* har en plads lige ved siden af REST, som implementeringsteknologi.

Jeg ved ikke hvad der ligger af teknologi bag VANS... måske en anden læser kan hjæpe?

Jeg opfatter det heller ikke som om at du mener at en REST tilgang er rigtig til alt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere