[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> Eventually you need to figure out what the data, addressing and
> invocation model of your web service is. You cannot be
> "model-agnostic."
> You must decide. HTTP already gets you far down this path with its URI
> addressing model and 4 main methods for invocation. "Abstracting" over
> HTTP by erasing its model is not abstracting at all.
Yes, but can you have an abstracted model based on REST principles that can
be mapped onto HTTP in straightforward fashion? It seems so to me, though
I'm not an expert. However, as I've been absorbing the REST debate, I've
been going back and looking at the HTTP spec to see what things HTTP offers
that I can use, and I'm finding quite a bit of useful stuff that I just
haven't paid attention to before. Not many IT developers are goint to bother
with this. They'll follow the lead of their tools.
For example, a developer will have to think about how to handle error
conditions in their web service. Will they go to the bother of looking in
the HTTP spec and see what status codes are relevant to various conditions?
If they use a Java class library with an exception hierarchy in front of
their noses, and the framework knows how to map exceptions to the
appropriate 4xx or 5xx status code, they are more likely to write an
application that returns appropriate HTTP status codes. The framework could
offer established patterns for dealing with async vs. synchronous message
handling. It knows to send a HTTP status 202 acknowledgement; the developer
just thinks about what pattern fits the problem but doesn't need to be a
protocol expert.
It seems to me there is value in a protocol agnostic model built on REST
principles, and tools with "smart" bindings that know how to leverage the
protocol to support the model, rather than the "dumb" WSDL approach that
minimizes the protocol and views it as just transport.
|
