On Feb 10, 2010, at 8:38 PM, Jan Algermissen wrote:
>
> On Feb 10, 2010, at 6:40 PM, Paul Sandoz wrote:
>
>> Although as you say there are no guarantees there are good
>> probabilities that a documented service will not break clients by
>> removing documented features e.g. a link, of the payment type, MUST
>> be present in the representation for application/order+xml. Hence
>> there may be value coding for the probably case and managing errors
>> with exceptions.
>
> If the server sends a representation that does not conform to the
> corresponding specs (e.g. missing mandatory element) then that is
> surely an error on the server side and clients should handle that as
> an error condition.
>
Yes.
> What I am talking about is that the server cannot be constrained to
> send a particular media type (let alone Link headers). It might send
> application/order+xml for two years and the next day start to send
> an HTML representation of the order. Client side APIs should IMHO
> emphasize this and enforce proper client side implementation instead
> of leading client developers to think they can make any kind of
> assumption whatsoever.
>
So what you are saying is the client needs to declare to the server
what it accepts and if it does not get an appropriate acceptable
response then it is an error condition?
Paul.