Steve Vinosky over SOA, REST en serendipiteit

Steve Vinosky maakt een case voor REST als voorkeursstijl van Webservices. Naast de bekende argumenten (hij hamert met name op het caching/scalability-argument), vestigt hij ok de aandacht op de stelling dat REST-services, dankzij het feit dat het om standaard-methods gaat, veel makkelijker vanuit een "onverwachte richting" zijn te hergebruiken dan SOA-stijl services.

Hij noemt dat "serendipitous reuse". En hij stelt dat dit niet alleen voor het Web als geheel geldt, maar ook voor het reuse binnen de architectuur van een onderneming. Hij sluit af met:

"It's highly ironic that many enterprise architects seek to impose centralized control over their distributed organizations. In many cases, such centralization is a sure recipe for failure. A proven framework based on a well-constrained architectural style like REST allows for decentralized development that, because of the architectural constraints, still yields consistency. The Web itself is proof that this form of "control without controlling" works. In the long run, this approach is far more likely to achieve what architects seek than trying to enforce collections of ad hoc governance rules."

Zo.

Heeft ie gelijk? Ik denk dat het in ieder geval voor webservices die publiek zijn, en op het web staan te wapperen naar hergebruikers, wel waar is. En misschien ook wel binnen ondernemingen.

Maar dan moeten die REST-services wel netjes zijn ontworpen. Je ziet nu geregeld GET-commands die eigenlijk een POST-bevatten, of andersom. Dat is niet alleen lastig te begrijpen en dus lastig te hergebruiken, maar bovendien raakt de caching ervan in de war.

Vinosky heeft wellicht gelijk, maar maakt zich wel afhankelijk van het goede design van service-ontwerpers. Zou er een manier zijn om dat in goede banen te leiden, of moeten we hier gewoon rekenen op de natuurlijke selectie?

Want die natuurlijke selectie zal wel werken, op den duur. Als je drie services heb die alledrie hetzelfde doen, en een is met SOAP in de SOA-RPC-stijl ontworpen, een met HTTP, maar met de "verkeerde" method, en een derde netjes volgens de RESTful regels, dan zal op den duur waarschijnlijk de derde het meest worden gebruikt. Ceteris paribus, uiteraard.

En zo verdringt goed design langzamerhand slecht design, en worden de voorbeelden steeds beter.

Tsja, het kan natuurlijk wel effe duren.