On 09:59 PM, [email protected] wrote:
Great idea!
Please consider that when using cgi a complete REST over http style
interface is not supported: cgi defines only http GET and POST
DELETE and PUT are not in the cgi spec and handled differently by
different
httpd's.
A common convention is to allow a "_method" query parameter in the URL
to turn a POST into a PUT/DELETE. See
http://microformats.org/wiki/rest/urls .
It strikes me that Fossil is already quite RESTful and its URL structure
is quite conducive to a REST+JSON interface, using the convention of
"file extension implies representation".
e.g. "/timeline" produces HTML by default, but "/timeline.json" would
return the same information in JSON.
Similarly:
- "/wcontent.json" produces a list of all Wiki pages
- "/wiki.json?name=foo" is used to GET, POST, PUT or DELETE a specific
Wiki page
- "/info/HASH.json" produces a json representation of an check-in
- "/finfo.json?name=crypt_wp1.sql" produces a json history of a single file
- "/artifact/HASH.json" produces a json representation of a specific
artifact
I would imagine that it is not terribly difficult to set the default
representation to .html, and to detect requests for .json representation
at quite a high level (it's always the extension on the last component
of the URL), and simply render the output differently for those
resources that support a JSON representation.
With some carefully designed helpers the same logic could be used to
produce JSON or XML or whatever next year's favorite happens to be
(along the lines of rep = "json" /* or whatever */; s = new
StructuredOutput(rep); s.put("name", type, "value"); output = s.render(); )
Regards,
Twylite
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
