On Fri, Sep 9, 2011 at 7:04 PM, Twylite <[email protected]> wrote:
> e.g. "/timeline" produces HTML by default, but "/timeline.json" would
> return the same information in JSON.
>
i like that idea. i hadn't thought of simply using an extension. i don't
have a strong opinion as to whether, e.g. /json/stat or /stat.json is
better. Anyone want to give me their own strong opinion? (We could probably
support both - they're stored as string-to-function mappings, but the
current path/arg-handling code would need to be slightly different for each
case.)
Similarly:
> - "/wcontent.json" produces a list of all Wiki pages
>
That's what i'm working on at the moment, actually.
- "/wiki.json?name=foo" is used to GET, POST, PUT or DELETE a specific Wiki
> page
>
i can't say i'm comfortable with handling PUT/DELETE requests, but i say
that because in some 15 years of programming web pages i've never once had
the need for them (and thus don't know off-hand what they're for, their
semantics, etc.).
i know i shot myself in the foot by incorrectly using the term REST. REST is
not truly what i meant, but (as Martin pointed out), "JSON over HTTP." It's
simple, straightforward, and doesn't rely on any
tricky/uncommon/non-standard semantics.
- "/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
>
All good ideas.
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.
>
Because JSON output has to be "pure JSON" and fossil has a long history of
relying on HTML/console output, i'm having to be somewhat careful in where i
can add/generate output. In particular, error handling can be problematic
because db_err() and friends assume HTML/console modes (which i've just
patched in my copy to generate JSON error responses).
_In general_, but not quite 100%, the various existing commands/web pages
contain one or more SQL commands which we can use as-is for generating json
payloads. In some cases i can merge the two without much work. In some cases
i have to factor the SQL prep into a common routine so that both the
original command and the JSON variant can use it. In one case (/json/stat,
which will now likely be renamed to /stat.json) i ended up copy/pasting the
SQL because for that particular case (with many queries) it's easier to have
two separate impls than to combine them.
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(); )
>
Absolutely. In fact, the JSON layer uses a DOM-like approach. You create a
JSON array/object tree then format it to whatever output channel you want
(it streams input/output via callbacks). Because it's DOM-like, we can
transform it to XML instead of JSON.
FYI:
http://fossil.wanderinghorse.net/repos/fossil-sgb/index.cgi/json/stat
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
