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