Wednesday, September 16, 2009
The best laid plans ...
You go and do something with the best intentions and it suffers a few minor teething problems! With the benefit of hindsight I think we would definitely have gone about it differently, but at least it hasn't all been negative. Hopefully something good will come out of the various discussions, because that was always our aim!
Subscribe to:
Post Comments (Atom)
4 comments:
Update: I wish JJallowed comments. I'm still on the fence JJ. We just think that it would be beneficial for everyone to discuss applying REST, their experiences (for better or worse) etc. in a wider arena. Your input would be of interest too :-)
sorry Mark, I am lazzy, I sometimes just add posts to my feed without creating a permalink to it. Hence the lack of comment ability.
Glad to hear you are still on the fence. I am not sure though that the REST community likes any kind of formalism. It thrives on this "fuzzy" foundation that allow them to say "you don't understand what REST is". REST is clearly an "art".
In the end I don't understand the big fuss about all this. Creating an operation (a Verb) on a resource is mechanical in REST. You just post a related resource to the parent resource:
login -> POST session
submit -> POST submission
compensate -> POST compensation
...
Beyond that mechanic transformation, thinking that HATEOS works in a Server-to-Server interaction without a semantic foundation is pure Science Fiction. Even UDDI "discovery" mechanism is going to look feasible (have you thought about RDDI?)
What you are facing reminds me some of the dialogs I had with them in 2004 (Mark Baker in particular) when I was offering to create REST's metamodel in UML to help people see more clearly what the concepts were. The REST community does not want ANY clarity on its practices.
Good luck with your initiative, I do think you should find another name for it.
I am not sure whether this is one of the best laid plans or not, BUT I agree that there is nothing wrong in at least trying to document best practises from using REST and then see where that goes.
Standardizing a few conventions and providing some guidelines wouldn't hurt anyone -especially some RESTafarians who wish REST was employed more often in B2B, EAI, and related. Those people will not rest (pun intended :-)) their chances of success in conventions, vague definitions, and misunderstandings of proper usage.
Just my two cents here...
Just as if it was possible to use REST in B2B and EAI integration scenarios ...
JJ-
Post a Comment