<[EMAIL PROTECTED]> wrote:
>
> Right, so GET is more generic but the result is that I can get back a
> much broader variety of information - How do I ensure I get back
> something I can actually process usefully?
>
Ah, that would be the HTTP "content negotiation" facility (see Section
12 of RFC2616). For example, the client can specify the kinds of
representation formats it handles through the "Accept" request header.
Unfortunately, what you can put in here is not particularly useful in
specifying the semantics that your client understands. Just
saying "Accept: application/xml" or whatever is clearly insufficient if
you're looking for a business purchase order (for example) and only
know how to process one or two concrete formats (whether specified
through XML Schema or not).
Of course the semantic web folks would say that the necessary semantics
should be delivered (or otherwise made available) along with the
representation (e.g. through RDF). But if you really start with the
premise that client and server have no implicitly shared semantic
knowledge, the amount of RDF-like specification required to perform
anything remotely useful is unrealistically large.
The practical alternative, which I believe everybody is doing today is
just to make assumptions about the semantic understanding embedded
within client application code. Unfortunately, these assumptions
effectively form part of the service contract - it's just that they are
not written down. This is, I believe a major problem with the current
REST approach to machine-to-machine integration, which asserts
proudly "we don't need no stinking service description". You do -
you're just hiding it in your client application code!
-Mike.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
