[
Lists Home |
Date Index |
Thread Index
]
On Thu, 2006-02-23 at 21:55, Michael Champion wrote:
> That is, the REST debate has dope-slapped a lot of people who thought
> we should/would write new interfaces for every GetRandomThing()
> operation they might conceptualize. That is a VERY Good Thing. I
> don't, however, see much evidence that the "REST calculus" of
> GET/PUT/UPDATE/DELETE resources by transferring representations is
> actually used to model real applications of any complexity. Instead,
> people use GET for what it is obviously good for, and use POST as
> sortof a DoStuff() for everything else. In other words, most have
> learned to GET RESTfully, but just tunnel HTTP as shamelessly as any
> WS-* advocate for everything else.
But I think the hardest thing to understand about REST isn't the
semantics of the operations per se, but how exactly to define what the
resource is so that the operations make sense. If you do it right
(arguably), the semantics of the operations are established by the HTTP
specification. Then it's up to you to take your complex application and
figure out where and how to slice it up into resources. Based on
observation, I think this is where most people tend to get it a bit
wrong or otherwise go astray.
In my own case, I initially couldn't figure what kind of "resource" made
sense for what the object actually was. However, after thinking about
for a while, I realized that the resource I needed was something new,
related to but different from what was already there. Maybe I did it
wrong, but it was the best I could come up with from study of both Roy's
dissertation and the HTTP spec. However, this new critter which was
created via a POST operation was something abstract (in this case,
essentially a container for what I wanted to manipulate) which could
have an independent life from the data.
Since the resource was a container, it would always exist--regardless if
there was actually anything to go into it. When you dereferenced the
container via the HTTP verbs, if there was data, you got a
representation of that data. If there wasn't data and you did a PUT,
you created a new representation in the container, and when you were
"done", you deleted the container (in my case it was a transitive
operation).
I guess my point here is that unless the job is straightforward (like
you suggest) you may have to invent something else in order to make the
application play well with the HTTP verbs. If you don't, you just end
up with lots of overloaded POST requests (or worse: GETs with
parameters and side effects).
I think the other aspect is what your client is. If you have to support
browsers, then you're kinda stuck (AFAIK). If you're talking about any
kind of programmatic access (AJAX/other scripting, Java/C#, C/C++), then
you've access to the full set of HTTP verbs, and you can do what you
want.
When you figure out the right point of view, it works extremely well.
If you can't, it's often trying to put a square peg in a round hole. Of
course, that means it isn't a "press the magic button for a remote
interface" kind of game, but maybe that's not so bad. From what I've
seen in my work, there are some things that you just shouldn't try and
make too easy because the task requires you think differently.
ast
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
|
