Cart
[Home] [By Thread] [By Date] [Recent Entries]
Andrew Dubinsky wrote: > >... > > Does this criteria imply that all REST component methods must define > standardized API's prior to deployment? There is no need to define them. Except for the rare case where you have an extremely unique need, you use the methods built into the REST-aware protocol you are using. Today that is HTTP. > Or does it imply that REST developers must follow anyone that leads? REST developers follow the standard. > How does this account for interface versioning if the interface contract > is static (read: standardized)? Because the interface is so simple (at the method level) and extensible, the need for versioning drops, but does not disappear. There was HTTP 1.0 and now there is HTTP 1.1. There are a variety of tricks you can use including negotiation of new behaviours and the addition of new methods. > How do developers use the interface with assurance that it will not > change? It's like any other standard. You either trust the standards body or you do not. > How does REST handle multiple interfaces to the same resource? One way is through multiple URIs. Another way is through multiple content-types addressed by the same URI. > How does REST propose to extend interfaces? Through new headers, URIs and content types. > Does REST's constraints extend into data types and consistency across > interfaces? Don't know how to parse that question. REST does not say that all resources should share a common XML representation, if that is what you are asking. Obviously publishers need to deal with different data types than do airlines. REST acknowledges this and pushes *all* of the incompatibility down into the representations rather than having half of it in the representations and half of it in the method names and semantics. Paul Prescod
|
