[
Lists Home |
Date Index |
Thread Index
]
Andrew Dubinsky wrote:
>
>...
>
> I was not talking about the interface in the sense of protocol. That is
> intrinsic to the protocol handler, hopefully far below the application
> developer's view. In talking about interfaces, I meant to examine the
> issue in a COM interface sense.
REST doesn't support interfaces in a COM interface sense. There are XML
vocabularies and they have hyperlinks to other XML documents with their
own vocabularies. XML extensibility allows these vocabularies to evolve
quite a bit without switching versions. When version changes are
necessary, you can use content negotiation to give each client the
vocabulary it expects.
> ... Much of the problems I see with both
> SOAP and REST are the lack of a guaranteed, versioned interface contract
> between developer and service consumer. Methods and their parameters
> change over time.
REST predefines the methods (GET/PUT/POST/DELETE and minor
ones/extension methods). They change very slowly and rarely, with new
versions of HTTP, or with extensions to it. They have no parameters.
Change happens in the representations (typically XML vocabularies).
> ... Can REST create a strongly interfaced version system
> if the entire access method resides in the URI?
The URI is a pointer, like the bits that represent a C pointer. You
wouldn't do versioning there.
> ... Is that part of the
> specification? Should it be?
REST is not a single standard and has no single specification.
Paul Prescod
|
