05/30/08 :: [REST] See it for yourself [permalink]
Now that REST is being used by more and more people, it is becoming very difficult to hide behind a few general statements and hand waving. If you want to take all the measure of Stefan's comment on how application semantics are marshaled in REST:
I force my application semantics to adhere to the common HTTP semantics, which means that for every operation, I have to decide whether it's a derivative of PUT, POST, DELETE, or GET. POST is the one with the least meaning. So in the end, I mind end up with a mixture of mapping, some matching your alternative a), some matching b).
Look no further than the good old Wf-XML now dubbed Wf-XML-R for REST of course. What wouldn't you do to get a little bit of attention?
So after the easy stuff, GET /workflows, GET /activities... comes the "actions". With resources such as "Process Definitions", "Process Instances", "Activities"... you can't really avoid actions such as start/stop, pause/resume, deploy, activate... It happens they all have well established lifecycle (a.k.a state machine).
Remote Application needs to be able to start (and stop) a process instance
You bet ! So how do they map all these actions to HTTP? You may proceed directly to the 5.2 section of the document (get ready for a good laugh).
To create a new process resource, the Remote Application will need to use the HTTP POST operation.
...
POST /wfcs/workflows/{name}/definitions/{version}/processes
Thank god, Pete Williams started to solve the API versioning problem (they did version Wf-XML once), otherwise we would have had 2 {version} elements in there, one for the "Start" element, the other one for the process definition version.
They also re-invent WS-Security (not):
We will show later how to execute a similar workflow without requiring the user to type his user name/password in the request (which is not very user friendly)
Now, how do you Pause/Resume a process? Eeeeasy of course, you PUT something in it:
Remote Application updates a particular process (halt/resume)
PUT /wfcs/processes/51.atom
How do you Stop a process? even eeeasier, you DELETE it:
Remote Application deletes a particular process (stop)
deletes a particular process (stop) DELETE /wfcs/processes/51.atom
Don't miss the CRUD in section 5.3.1
Workflow Creation, Update, Delete
The Grand Finale is section 7.0: Event Notification
The workflow engine may have the need to notify users when resources change, processes are started and completed...
Well the remainder of the section is .... blank.
You can't secure this type of crap with robust authorization rules, you can't build tools, you can't assemble components...
I think at this point, I just want to throw up altogether. How can our industry have any respect for this kind of work, for the people that recommend going that way?
How can you ever expect that a set of technologies developed for a very particular usage pattern (Human/Browser/Server interactions and Feeds management) is going to work serendipitously for something else such as information system construction, connected systems...? After 20 years or more, you guys still don't understand the fundamentals of information system construction.