For reference, here is the pull request for changing the spec to use REST concepts: https://github.com/letsencrypt/acme-spec/pull/48
I've raised a few of these issues there, in particular idempotence. On 01/20/2015 07:39 AM, Phillip Hallam-Baker wrote: > Please, can we not use buzzwords? > > I have known Roy Fielding for 20 years and I read his original paper. > I have absolutely no idea what someone means when they talk about REST > and most times they mean 'perform some horrid kludge'. > > We are doing a JSON protocol here. That means > > All the request info in a JSON syntax request. > All the response info in a JSON syntax response. > > > Use of HTTP response codes results in flaky implementations because > intermediaries can meddle with them. You might want to give response > codes in both places but the canonical response code should be in JSON. > > HTTP does not add any value here other than providing > > 1) A mechanism for distinguishing multiple services on the same host > 2) Firewall bypass > 3) Providing a logical place to put a signature header > > HTTP was designed to support idempotent operations. ACME operations > are not idempotent so you are not going to get any benefit from HTTP > caching. > > > I have seen people try to make use of the URI line to encode a request > and the results are ridiculous and useless. You lose the ability to > have structured data for a start. And you don't get caching even for > static lookups unless you canonicalize the URI. > > > If we were going to spend time 'RESTifying' the spec then there should > be a description of what REST is published as an RFC and agreed by the > IAB that we are working from. Otherwise we just end up chasing > buzzwords without gaining any consistency. > > > On Tue, Jan 20, 2015 at 3:04 AM, Fraser Tweedale <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > After looking at the boulder server and the node-acme 'restify' > branch, and some discussion on #letsencrypt, I am led to believe > that work to make ACME a REST-flavoured protocol is underway. > > If this is the case, I have some questions/comments: > > - When will we see an updated version of the spec (be it in a branch > or otherwise?) > > - The Retry-After header can be used with response status 503 > Service Unavailable and MAY be used with any 3xx response. The > use of the Retry-After header in the restify branch seems to be in > violation of RFC 2616. > > - I'm not sure that REST is a good semantics for ACME (what does > revocation look like, for example?). What was the motivation for > switching to a REST-esque API? > > Regards, > > Fraser > > _______________________________________________ > Acme mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/acme > > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
