Jean-Jacques Dubray on processes in a RESTful world:
At this point, I start wondering who is not writing any code. This is why I am a bit upset at the REST community, at Stefan and Bill, and others. Only you, have the concept of a resource within your programming model. This is the opportunity to revolutionize the way we construct information system, this could be a benefit almost as big as the web itself. Yet this community wastes all its time, and other’s time, trying to funnel all application semantics through two verbs. That’s all they care about. In the process, they have lost sight completely of what a resource is.
Perhaps we’re just not talking about the same resources.
This is also a question on GET with respect to “search”, can “search” be modeled in a RESTful way? I am not sure the answer is yes, but that’s secondary
Obviously we’re not talking about the same resources.
Entities have IDs. Resources have URLs. Services have endpoints. That’s an arbitrary distinction I’m using here, if you think entities have URLs, let’s just agree to call them resources for now. Entertain me.
An entity is the notion of data. A service is something you can use. The two work nicely together, just have a look at WS-Addressing (complex, but that’s not the point) or the SalesForce API (SOAP abusing, but again, not the point). Resources exposed via well-groomed endpoints and entities work, I hope we’re all in agreement with that. Unfortunately, it works in a world of application silos closed off by WSDL service definitions.
RESTful resources are in charge of their location, operations you can do against them, and their representation. Operations go beyond four verbs, that’s the very essence of responses returning even more URLs. Likewise, you can break complex problems around multiple resources. Not sure how it works? Read Stefan Tilkov’s intro to REST.
So we’re starting with the same capabilities, but adding more to the mix. Mobility which lets you open up to more resources than the SCA walled garden admits (at least in its current incarnation). Uniform access to the data, so you can index, archive and monitor it. People, which is fairly easy to do given URLs and multiple MIME types. Testing and troubleshooting, we all know clever code requires beyond-clever people to fix — anything demanding tooling is by its own admission too clever for production.
In this world view, moving from SOAP to REST is opening up your services to new possibilities, adding more actors, and simplifying to great effect. The analogy I’m looking for is adding more verbs to the existing one, not restricting, after all, you can’t go lower than one.
At the end of the day I can’t care less about which protocol the REST community, Microsoft or IBM wants me to use, all I care about is having the correct application semantics to build composite information systems. That’s all I need, that’s all I want.
I think what JJD is alluding to here is higher level state transitions beyond “hey, I can PUT a new price on that item”, and that was somehow confused with REST, which is why the post made no sense on the first read. So let’s separate those higher level abstractions form the underlying layer, which can be either RPC or REST. Except good luck fixing foundation flaws with higher level abstractions. If it’s REST all the way down, you get to build on the benefits of REST; if it’s RPC, it’s something else you’re building on.
Higher up the stack we find things like RESTful BPEL. RESTful BPEL is one particular way to express those higher level state transitions, like “let’s go from pending to approved”. It lets you say things like “this GET returns ‘pending’, and so the next PUT allows changing to ‘approved’ or ‘rejected’”. That sort of things, which I guess is what JJD is talking about.
And it does so with REST so you can GET the current state any number of times, neither of which changes the state of the process, which helps when the next thing you do is a conditional PUT. It lets you layer a UI on top of the process, again just a matter of alternate presentation on those URLs. You can run a search engine on all your process instances, search engines thrive on GETs and URLs. And yes, it works better for dynamic languages.
Obviously the reverse is true, you can use resources without nose bleeding from service-ref overdose, and access CRUD resources as variables. That’s possible because we can tell the difference between GET and PUT and know how to run an atomic assign using ETag and Last-Modified. Possible with SOAP, except everyone does it their own proprietary way, so now we turned a supposedly uniform protocol into another integration headache.
So in the end, what JJD is seeing is a retreat to less capabilities, which obviously makes no sense. What I’m seeing is people stepping back to rethink those 1st generation services and all the mistakes we did around SOAP, and planning out 2nd generation services, doing things simpler and better with the help of REST.