[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MUST a collection be returned as an Atom feed?
Aristotle,
I think I see where we disagree or misunderstand each other: In my
understanding, it is part of the semantics of application/atomsrv+xml
that a service that sends that media type to describe itself
constrains itself ('promises') to conform to RFC 5023. In our example,
it promises to return an Atom feed upon a GET request to a collection.
I hear you saying that your opinion is that a separate business level
contract should exist (if desired) to constrain the server to be RFC
5023 conforming.
Comments in line...
On Jan 2, 2010, at 10:05 PM, Aristotle Pagaltzis wrote:
* Jan Algermissen <algermissen1971@xxxxxxx> [2010-01-02 21:20]:
* 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).
That’s what I addressed in the following part of my message that
you didn’t respond to:
I did not respond because I thought it was obvious that they
communicate based on RFC 5023 when the server sends an AtomPub service
document describing itself and the client then bases its expectations
on that.
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.
But anyway:
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?
If the kernel returns EINTR when you try to open a file, and you
don’t check for an error and hundreds of records are lost, who is
liable?
The same person in both cases – whoever wrote the client.
Yes, but you are referring to a condition here where the client's
expectation still holds and handling the condition is well described
by the API. The client developer knows any possible situation at
design time and any behaviour outside that contract is a failure of
the service, not the client. But then - I see that we agree on RFC5023
mandating the return of an AtomFeed and that a 406 return would be a
validation of the contract provided by RFC 5023.
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.
Do you write business systems that don’t check the return value
of `open`?
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.
No, that’s not what I’m saying. I said explicitly that if the
server is to conform to AtomPub, it MUST send an Atom feed. If
the server does not send an Atom feed, then necessarily it does
not conform to AtomPub.
See initial sentence of mine.
Overall, I am really only concerned with the issue that I think that
the fact that AtomPub requires an Atom feed to be returned for the GET
to a collection is a violation of RESTs hypermiedia constraint because
the client makes an assumption of the returned hypermedia (==possibly
available transitions) at design time instead of finding what is being
returned at run time.
However, I consider such a contract inevitable in M2M (non crawler)
scenarios and my original intention was to hear if others would agree
that such contracts should be very explicitly stated in specs such as
RFC 5023.
[BTW, over on rest-discuss I was unable to get anybody to agree that
RFC5023 in fact *requires* the return of an Atom feed]
Now, the client shouldn’t blindly expect the server to conform to
AtomPub just because it’s in the business contract or because the
server sent a service document, any more than it should blindly
expect `open` to always succeed.
Well, here is our disconnect. I do think that a client that does a GET
on some service URI /foo and receives application/atomsrv+xml can
expect the service to conform to RFC5023. IOW, a service that tells a
client via an AtomPub service document that /foo/col is a collection
MUST send an AtomFeed for a GET on /foo/col. I do not think that a
separate business level contract is needed that states: "The service
located at /foo conforms to RFC 5023".
But you are confusing two levels of agreement here: agreement on
what RFC 5023 means, and agreement about an obligation to comply
to RFC 5023.
I do not think I am confusing this. I think that sending a client an
AtomPub service document is a service-side commitment to RFC5023. But
rather than fighting over that interpretation - I'd be curious what
other think.
Obviously the latter cannot be achieved without the former, but
they are still distinct levels of agreement. RFC 5023 is limited
to the former in scope. You will not find answers to the latter
in it.
What if there is an SLA liability fee pertaining to the
availability of the reports?
That’s the SLA’s job to define, not RFC 5023’s.
I do not think that SLAs need to contain statements like "services
that return application/atomsrv+xml conform to RFC5023" - I think that
is inherent in the semantics of that media type.
RFC 5023 can only set the parameters for compliance to AtomPub.
What does that mean?
If you agree on a contractual obligation for compliance to
AtomPub, that’s your business decision, it’s not a policy within
the scope of RFC 5023.
I disagree. A component that exposes file access through the IO API
you refer to has a contractural obligation to conform to the API spec.
There is no need for a separate business agreement that exposing the
IO API means to comply to the API definition.
Thats nonsense because nobody can implement a client without an
expectation what might be coming back.
Well, if you can’t open a file, or committing a database
transaction produces an error, or memory allocation fails, then
likely the code is at a point where the error cannot be handled
gracefully and all it can do is die screaming.
Sure. And that would, for example, be covered by some sort of downtime
agreement. But a RFC 5023 compliant service that sends RSS instead of
AtomPub for collections would not consider itself to be in an error
condition, right?
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.
Is this supposed to be some sort of argument?
Irrelevant by now because we seem to agree that the 406 would be a
breaking of RFC5023.
Jan
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).
Of course.
See above.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--------------------------------------
Jan Algermissen
Mail: algermissen@xxxxxxx
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------