[
Lists Home |
Date Index |
Thread Index
]
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
|
