On 3/15/06, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Hey Joe,
>
> first pass over this raises a few concerns from a purely spec
> interpretation point of view (I'm thinking interop here, NOT
> feedvalidator politics). Comments on each test are below.
>
> * GET should support the use of ETags and/or Last-Modifed cache validators
> * GET should support the use of compression to speed of transfers.
>
> Both the Atom format and app specs are silent on this. My
> implementation currently supports Last-Modified, but doesn't support
> ETags or compression, and yet we are fully-conformant to all of the
> MUST's and SHOULD's in the spec. Regardless, I don't think we can
> reasonably expect implementations to do adhere to any SHOULD level
> requirement that isn't actually in the spec ;-)
Actually, in the test code there are three levels: errors, warnings and
suggestions. Errors are reserved for MUST level violations, warnings
for SHOULD level violations and warnings are for things you really ought
to do. Cache validators and compression are currently suggestions.
> * Atom entries and feeds MUST be valid
>
> Yep, this is fine.
>
> * A server should reject content if not given a content-type
> * A server MUST reject non-wellformed content
>
> These aren't. Our implementation will reject POST's that do not have a
> content-type, but there's nothing in the spec that dictates that it
> should be there.
>
> Further, our implementation is will likely, to a limited extend, accept
> invalid atom entries in the spirit of postel's law. It's going to be
> very difficult to dictate to server implementations what they should do
> in these cases and I don't think it's worthwhile to try.
>
> * When an entry is successfully created the server MUST return an HTTP
> status code of 201.
>
> I'm fine with this, but the spec doesn't say "MUST". should it?
Hard to tell, the current wording is:
""If the Member resource was created successfully,
the server responds with a status code of 201""
Are other status codes ok? I think this is ambiguous.
> * When an entry is successfully created the server MUST return a Link:
> HTTP header.
>
> Error. I think you meant, "MUST return a Location: HTTP header" ??
Correct, I'll update the text.
> * When an entry is successfully created it must be added to the
> associated feed.
>
> Fine with me.
>
> * When an entry is successfully deleted the status code MUST be 200.
>
> The spec doesn't dictate a response for this. In fact, given that the
> response payload is likely going to be empty, 204 would likely be more
> appropriate and is the response code we currently return in our impl.
> Regardless, any of the 2xx responses, or even a 3xx response could be
> appropriate.
Now updated to only report an error if the deletion failed (status
code >= 400).
> * When an entry is successfully deleted it must be removed from the
> associated feed.
>
> I'm fine with this, but this isn't actually ever stated in the spec.
> Change it to a should and I'd be happier.
So you believe we need more spec text here?
> * The link/@rel="edit" URI must match the URI returned via the Link:
> HTTP header during creation.
>
> Do you mean Link header or Location header?
Correct, I'll update that in the test suite also.
>
> * The link/@rel="edit" URI must be dereferencable.
>
> Fine with me.
>
> Overall, I think this highlights a few potential areas of impl
> confusion, mainly around the area of what kind of responses to expect
> from the server on various requests. For instance, we had a discussion
> internally about what should happen when an entry is deleted. In the
> original implementation, a DELETE resulted only in the flipping of a
> metadata flag on the entry (e.g.,<deleted>yes</deleted>). Subsequent
> GET's on the entry URI would still return the entry which would also
> continue to appear in the feed (with the deleted bit set). I changed
> that behavior so that subsequent GET's on the entry URI return a 403/404
> and the removal of the entry from the feed.
>
> In any case, good stuff overall.
Thanks.
>
> - James
>
> p.s. our endpoint is actually ready to go up for public testing. given
> that this is pre-release product code, the one thing holding us up is a
> thumbs up from our legal staff which should (hopefully) come this week.
>
-joe
--
Joe Gregorio http://bitworking.org
