On Fri, Aug 17, 2012 at 10:26 PM, Stephan Beal <[email protected]> wrote: > On Sat, Aug 18, 2012 at 5:17 AM, Nico Williams <[email protected]> > wrote: >> What's not RESTful about it? At first glance I see it uses GET and >> POST appropriately, not using GET to create things, using POST to >> create/modify things. It doesn't use DELETE, but then that's because >> Fossil deletes nothing, right? As for PUT... POST for creating >> resources seems to be more popular now. That leaves the non-use of >> HTTP status codes, IIUC. But I do think that HTTP status codes should >> be used, and it's OK to deliver more application-specific status codes >> in the response entity. > > > It's probably splitting hairs, but by the Wikipedia definition of REST, the > JSON API is not REST, and i caught some flak for calling it a REST API early > on in the development. Aside from the use of HTTP result codes (which i > despise), CGI (which fossil uses even for built-in server mode) does not > specify PUT, which REST does. So it's officially "not REST" ;). But yeah, > it's REST-enough, IMO.
Given that PUT is for replacing PUT has no more place in a Fossil RESTful API than DELETE. That leaves the non-use of HTTP result codes. But what's the problem with returning both, an HTTP status code and an application-specific one in the response entity? Doing so would leave you with a RESTful API and your clients can just ignore the HTTP result codes. Let's put it this way. To return 200 for a POST that actually failed is very strange -- the response entity had better, at the very least, not be cacheable if you'll do that. Nico -- _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
