On Apr 2, 2017, at 2:48 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > a) that's essentially what the JSON API is
…minus the lightweight Subversion-like client, of course. But, it’s good to know that most of the work is already done. > with the notable exception of missing blob support (since JSON has no > definition for blobs). When I said that the default return representation should be JSON, I did not mean that all data must be in JSON format. I just mean that, when no better representation exists, the API should use JSON. Contrast the Fossil HTTP API here, where sometimes pulling a specific file shows it in the browser as-is, sometimes it displays it inline with other material, and sometimes it downloads it. The Fossil HTTP API knows it’s talking to a web browser, and that a human is likely driving that browser, so it is trying to present the information in the manner the human most likely wants it. With this REST API, I’d expect to get a file download every time, because the server cannot make any assumptions about the nature of the client, particularly about the display semantics. Web applications like Fossil UI often make such assumptions. The REST API would be more policy-free, in this sense. > b) CGI does not specify certain methods which REST conventionally relies on, > most notably PUT. PUT is nice to have for REST, but not essential. The typical need for PUT vs POST is to distinguish “insert” from “update” — to put it in SQL terms — but that’s just one flavor of REST. Another flavor distinguishes the cases based on whether you give a record ID or not; if not, it’s “insert.” The PUT vs POST idempotency distinction also works in our favor here: it’s better that the one verb we get be the one that doesn’t try to guarantee idempotency. > A strictly-REST-compliant API Who specifies “strict” REST? All I see are a bunch of cliques and camps, no actual standards. That said, if some of this didn’t work with CGI, I don’t see a problem with that, since it is merely one alternative way to access Fossil, not the main one. If the requirement is that you use “fossil server” with this, that seems fine to me. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
