On Mon, Sep 12, 2011 at 11:33 AM, Stephan Beal <sgb...@googlemail.com>wrote:
> On Mon, Sep 12, 2011 at 1:26 PM, Richard Hipp <d...@sqlite.org> wrote: > >> There should be links. Without them, the interface is not fully RESTful. >> See http://martinfowler.com/articles/richardsonMaturityModel.html for >> further information. A key idea behind REST is that an application can be >> given a small number of "starter" URLs and it can discover all the other >> URLs it requires by following links. >> > > That assumes, though, that the clients understand HTML. If the data which > is currently provided as links were provided differently then we might be > helping non-HTML apps rather than hindering them. For example... > (spontaneous idea, not something i've yet tried...) > Anchor tags in HTML are just one mechanism for providing hyperlinks. In JSON, you could just as easily invent an alternative mechanism. Perhaps an object: { "LinkType": "Next", "URI": "http://www.fossil-scm.org/fossil/json/timeline?first=12345"; } So, for example, the JSON that comes back from a timeline request might include multiple links such as the above that describe how to get the previous or next timeline, or a longer timeline, or timelines for specific branches, and so forth. The idea is that resources can move around (move to different URLs) and the client-side application doesn't need to know about it. As long as the starting URLs are the same, the client will discover the other URLs automatically. I'm not saying this is necessarily the best way to do things. But it is the RESTful way to do things. > > Commit message: "merged with version [abacab] and cherrypicked [defdef]." > > One idea for the JSON impl would be to run that text through a different > parser, which translates it into a compound object containing: > > a) The original commit string (unparsed). > a.5) possibly also the HTML-parsed form. > b) elements describing the links. > > Just off the top of my head, something like: > > { > plain: "merged with version [abacab] and cherrypicked [defdef].", > html: "merged with version ...whatever the web interface shows...", > references: ["abcacab", "defdef"] > } > > or: > ... > references: ["/json/vinfo/abcacab", "/json/vinfo/defdef"] > > That "might" improve the discoverability aspect while also not directly > hindering non-HTML clients. > > > Since spiders that follow JSON are not currently a problem, I think it >> would be OK to disregard the History permission on JSON-returning pages. >> Just keep in mind that at some point in the future, we might need to revisit >> this decision. So please don't paint us into a corner. >> > > As the other answers to my original post pointed out, my initial vision of > authentication was kinda "1969, free access for all," and was obviously > way-oversimplified. i'm punting on the auth problem for the time being in > order to look closely at fossil's impl to figure out how best i can > integrate with/to it. i don't want to rush into an impl, because > authentication as a problem domain is a minefield. Fossil's model is just > fine, i just need to figure out how to mesh with it. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
