On Fri, 17 Sep 2010 10:23:58 -0700, Paul Berry wrote: > > On Thu, Sep 16, 2010 at 6:30 PM, Luke Kanies <[email protected]> wrote: > > > On Sep 16, 2010, at 1:24 PM, Paul Berry wrote: > > > > On Wed, Sep 15, 2010 at 11:35 AM, Luke Kanies <[email protected]> wrote: > > > >> Shouldn't 'none' be a valid state? Or maybe 'unknown'? I would think > >> that's different from 'invalid'. > >> > > > > Do you mean if the user requests information about a host for which there > > is neither a certificate request nor a certificate? I think I would prefer > > to use a JSON "null" value for this case (equivalent to Ruby's "nil"). That > > would be more consistent with the existing REST API's and with the semantics > > of "certificate_statuses". > > > > > > I'm inparticular about the actual term, just that we have something for > > hosts with no information at all. > > > > Hmm, I just did some more experiments and some more thinking about RESTful > protocols, and I've changed my opinion. I now think that what we should > actually do in the case of an unknown host is return an HTTP 404 "not found" > error. This would be easy to implement, and consistent with what our other > REST APIs do (for instance the existing APIs for requesting certificates). > It would also be consistent with other RESTful protocols (such as the REST > API for Amazon S3--see > http://docs.amazonwebservices.com/AmazonS3/index.html?ErrorResponses.html). > > Does this sound reasonable? >
+1 for using the HTTP response codes when they accurately describe the "failure" mode. -- Jacob Helwig
signature.asc
Description: Digital signature
