Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
