Lists Home |
Date Index |
Dare Obasanjo wrote:
> However, since on the Web we actually use HTTP GET for fetching RSS
> feeds, the fact that some new use of RSS shows up doesn't mean people
> like me have to rewrite clients to support them [modulo supporting
> extensions to RSS].
Thats it exactly.
> It took a while to figure what the uniform interface argument was about
> but now I think I get it.
As an aside, I think people tend to learn the REST architectural pattern
in stages. Once you've nailed down the uniform interface aspect, then
there's the "hypertext as engine of application state" bit. I've been
wrestling with that one recently.
It largely boils down to ensuring that your response documents include
hyperlinks, so your client, which understands that uniform interface
knows that it can GET those links. It may or may not be able to do
something useful with the responses.
Many "RESTful" interfaces currently return chunks of XML containing
say "person" or "city" elements, often with unique identifiers. Other
parts of the service can take those identifiers and return more
information about each resource. But you need to teach your client how
to construct those URLs, unless the XML has the links in it.
So, by introducing a uniform interface you make your client more
general. But without hypertext you still need to teach it about the
details of the API.
By introducing links between resources, you generalise a step further.
Which brings you up against the problem of teaching your client about
specific document formats.
By standardising those formats you reach another level of generalisation.
There's a step beyond this which takes us to RDF...