[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: APP Test Suite



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 ;-)

* 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?

* 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" ??

* 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.

* 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.

* 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?

* 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.

- 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 Gregorio wrote:
> I have added the APP Test Suite to the Feed Validator subversion
> repository. This is a Python script that, when passed in the
> URI of an Introspection document, will test each entry collection
> for conformance to the APP. To run it you will
> need Python 2.3 or greater.
> 
> To get the source:
> 
>   $ svn co https://svn.sourceforge.net/svnroot/feedvalidator/trunk/apptestsuite/
> apptestsuite
> 
> To run:
> 
>   $ cd apptestsuite/client
>   $ python appclienttest.py\
> http://bitworking.org/projects/pyapp/collection.cgi?introspection=1
> 
> Atom Client Tests
> -----------------
> 
> Testing the service at
> <http://bitworking.org/projects/pyapp/collection.cgi?introspection=1>
> Running:  . . . . . . . .
> == Errors ==
>   No problems found.
> == Warnings ==
>   No problems found.
> == Suggestions ==
>   No problems found.
> Success!
> 
> The test suite incorporates the feedvalidator to test all responses
> for conformance to the Atom Syndication Format. It also uses
> the httplib2 client library. Through the magic of
> subversions svn:externals property, local copies of both of
> these libraries will be automatically pulled down when you check out
> apptestsuite.
> 
>    Thanks,
>    -joe
> 
> --
> Joe Gregorio        http://bitworking.org
> 
>