[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MUST a collection be returned as an Atom feed?
On Jan 2, 2010, at 5:15 PM, Aristotle Pagaltzis wrote:
* Jan Algermissen <algermissen1971@xxxxxxx> [2009-12-28 18:10]:
Given it is a MUST requirement, it can be said that clients can
make the assumption to receive an Atom feed document as the
response to a GET request to an AtomPub collection resource.
Yes?
No.
The server is free to return anything it wants.
Easy to say that - but the issue is really: If a server tells a client
it is an RFC 5023 compliant server (by sending the client an
application/atomsrv+xml service document) the client will expect to
receive an Atom feed as a response to a GET on a collection (based on
the contract defined by RFC 5023). In fact, you cannot code anything
useful without such an assumption in an M2M scenario.
When the server returns a 5xx and hundreds of business transactions
are lost - who is liable?
It makes no sense to answer to this that the server is not (or in fact
can *never* be) liable because no client may make any such assumption.
You can write blog indexing crawlers based on that but not business
systems where the client necessarily! follows its own sequence of goals.
See it this way: How does the service owner know, in what way the
service can evolve without breaking the interactions that the service
enables in the first place. You position would be that it is perfectly
ok for the service developer to abandon Atom feeds completely and send
some nes stuff instead as long as a proper HTTP error code is being
sent.
If such as service is built to enable clients to submit and review
incident tickets and some M2M clients suddenly are unable to proceed
because no Atom feeds are being returned anymore (but 406 Not
Acceptable) the effect could be that promised reports cannot be
delivered to some customer anymore. What if there is an SLA liability
fee pertaining to the availability of the reports? Is the provider not
liable because the client should not have made any such assumption
ablut the service in the first place?
Thats nonsense because nobody can implement a client without an
expectation what might be coming back. Saying that the client should
be able to handle 406es by calling the dev team to quickly adapt the
client to the changed server would not be agreed upon by any client
owner.
No matter how loose coupled HTTP or AtomPub is - the contract exists
in some form anyway and can be broken (including 406es). If it breaks,
someone is responsible and it is pretty sure that putting the
responsibility on the client makes no economic sense (in M2M scenarios).
Jan
The trivial case
is a 5xx response, of course.
However, if the server does not return an Atom Feed Document,
then the client and the server cannot interoperate.
More correctly, they cannot interoperate based on the rules of
AtomPub. Maybe they can still interoperate based on some other
protocol – that’s fine. But they cannot interoperate on the basis
of compliance to RFC 5023: RFC 5023 has nothing to say about such
an interaction.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--------------------------------------
Jan Algermissen
Mail: algermissen@xxxxxxx
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------