HTTP!=REST is an important equation. Unfortunately, it requires familiarity with the RHS as well as the LHS to see why the inequality holds. I hope some day we will get there. Right now, in simple English, here is the problem as I see it:
the lack of a simple, reliable messaging mechanism is severly curtailing advancement of the RESTian cause.
Developer A: I need process A to talk to process B using internet/intranet protocols. I was thinking of using HTTP PUT or POST
Developer B:That won't work.
Developer A: Why not?
Developer B:Because HTTP is not reliable. What happens if a PUT/POST fails with a timeout? By the time you get the error, it is too late. You don't know if the timeout was a network thing or a process thing. You will end up resending stuff that already got there and not resending that didn't.
If I was you I'd use web services instead.
Developer A: Why?
Developer B: It provides APIs for all that stuff.
Now, I'm in the camp that believes that APIs for this stuff is not the right answer. It blows the non-API everything-is-a-document-dude beauty of, for example, HTTP. It plays directly into the hands of those who would prefer (for a variety of reasons) to re-invent the web rather than use the one we have got for process-to-process integration.
All I want for Christmas is HTTP RPOST and RPUT methods, the return codes of which, tell me whether or not the resource at the end of that URI actually received the POST/PUT.
No comments:
Post a Comment