Yes apparently my babble is causing unREST.
Mark Baker thinks I speak rubbish in my Poor Service Semantics post.
But Mark is just shifting around where the semantics of what your doing is. That's all. All this RESTing has him confused. ;-)
Look
when you get down to it everything (in this service world) is just a
string coming over the wire. Web services, REST, CORBA etc. are just
arguing where the unwrapping of the string occurs.
Take CORBA for example. When you look down into it there is
basically one operation called a Request that puts a big blob of data
(a document?) on the wire. At some point the data gets unwrapped and
examined and a dispatch to piece of coded logic (the business) occurs.
So is CORBA RESTful?? Is the Request just really a PUT in disguise?? ;-)
Either you have one location and you put and the semantics of what
your doing (the operation) in the document - e.g. orderItem. Or there
is a different URL location for each operation. So either the document
semantically tells you what you want to do (and you still need to
dispatch to the right code) or else each location only performs one
operation and you only send the data there. Actually the former sounds
very like CORBA ironically. I.e the CORBA dispatcher sends the data to
the right location of the business logic. ... But then so does the
later. Wow CORBA is definitely not supposed to be RESTful but sounds
like it. (I'm being factitious) The reason can you look at it both ways
is that again at some point you need to dispatch a piece of data to a
specific piece of code and at that point it becomes very "tightly
coupled" no matter what the technology. Is a RESTful internet just a
big ORB? Well I'm sure many of the REST folks would just say so.
I get back to my point. Everyone is getting bent out of shape about
this and really it's just a matter of where the big string of data gets
unwrapped and who wants to do the unwrapping. But when you do pick a
particular technology to do your unwrapping then you take advantage of
the capabilities of that technology. And in CORBA a runIT (in String blob)
where there is a dozens of business functions hidden in the string, is
definitely not taking advantage of the underlying infrastructure and a
waste of money.
The big issue not whether a PUT or orderItem
is better. That depends on the technology being used. If REST provides
a great framework for maintaining, tracking, documenting etc. the real
location and semantics of the operation then I think it's great. I can
definitely see where REST makes a lot of sense. There is a LOT of waste
and misunderstanding in other technologies. (There is a whole lot of
complication in CORBA that I thought made it inaccessible to many
developers and would drive anyone to a more RESTful state of mind).
Imagine if the anchor tag of a hyperlink didn't allow you to specify
any source. Imagine if it had an implicit "GET" as the source. So on ay
web page the only semantic you had was "GET" as the link to the
underlying href. Hyperlinks would be rather boring and not very well
documented. And that's my point the semantics need not only be there
for the operation but also for understanding the way the business
works. Where the semantics are depends on the technology used and how
rich it lets you document those semantics.
I'm looking forward to understanding more about how that works in
REST. Perhaps it's just brilliant. Remember I was the one advocating
using RSS feeds as a service lookup repository instead of UDDI a few
months back. Boy it doesn't take long to fall from grace.