On Fri, Sep 9, 2011 at 7:38 AM, Martin S. Weber <[email protected]> wrote:
> are talking about REST and JSON, but you really, really mean JSON > over HTTP. What I'm trying to say is that you seem more concerned > Yes, i am very possibly abusing some terminology. :/ Feel free to set me straight. > preference of using POST to fetch multiple resources, where I'd > rather expect a matrix parameter in the URL (values separated > by semicolons). > Old habits die hard. I'm wondering about the rationale behind establishing a set of > return codes stuck into the JSON. If you are getting this via a > REST request, we do have the HTTP request status codes. Again, it's my abuse of terminology. We could certainly add an option/mode which uses different HTTP result codes. My planned uses would be mostly from JS code which wants a nice, clean HTTP 200 (because i've already got a lot of code which uses this model and it clean separates transport- and app-level errors). of return codes buried inside the JSON. In fact, in an error condition, > to avoid leaking information about how you might actually attack > the server (DOS or breaking in), you should not be too specific > about the error cause to the user. All that matters to the user > is something like: wrong request, not authenticated, transient > error, permanent error, resource moved, ... etc. > The current error codes model takes that into account by allowing the codes to optionally be "dumbed down" by moduloing them with 1000 or 100 (depending on the level of dumb-downedness). > All of this can be (and has been already) modeled via HTTP > status codes. Have you got some links for me? > FOSSIL-0: We have a successful http status code and are getting > data. Yes the request has been successful. It's not necessary to > duplicate this information. > Actually, my intention is to remove 0000 from responses (as i do in my other code), since it is redundant (_except_ that it verifies that the response is-a fossil response, but that's not strictly necessary). > FOSSIL-1001: We don't need a request envelope, and we shouldn't > require one. The majority of the requests should be HTTP GETs, > and all their data should be in the URL. No JSON at all in the > request part. > The envelope is only used for POST, and will (IMO) be needed when dealing with, e.g. the authentication info (which should not be passed in via GET because that lands in my apache log). We can't rely on cookies for auth info because not all clients can use them. (But we can piggyback on/integrate with the current fossil cookie mechanism, i think.) FOSSIL-1002: unknown command = URL not found. There's a status > code for that (404). > My client-side AJAX code will fail in ways its not programmed to if a non-200 comes back, which is why i modeled it this way. i.e. it treats non-200 as a transport-level error, whereas with this model a 200 says that HTTP-side everything was okay but the error code reveals an app (not transport) level error. FOSSIL-1005: If a server side timeout occurs, the client making the > connection will / would timeout on its own. Otherwise, use 408. > fossil doesn't do any timeouts itself, AFAIK (maybe under high concurrency?), so i think this one can go away entirely. i basically just copied the list of error codes from a different project of mine. ...FOSSIL-6666: We definitely don't want a (evil) user to know > that. Generic error it is. > Good point. > FOSSIL-6667: Actually, 500 (or 400) is a good response on that. > i also can't argue against that. > Loose thoughts: > > For someone who is used to using REST services, the necessity > for a JSON-based POST when you really want a GET seems awkward. > POST is only needed for some requests. We can't save a 12kb wiki page using GET only because GET is often limited to 8kb or less (and some web servers segfault if sent more). Also while we're there (and I'm thinking about shunning now), > HTTP DELETE should probably be on the list of supported transactions. > > Definitely HTTP PUT for editing stuff should be there (to keep > things natural wrt REST). > > I don't like the requests that pass parameters (list?page=, > wiki/get?name=). They make the URL unnecessarily longer IMO. > my personal preference is /path/style. > json/wiki/save should be a PUT/UPDATE. > > The Pun: Was man ueblicherweise mit fossilien macht, ist sie > auszugraben und auszustellen. "Ausgrabung" waer daher ein passender > Name (Excavation). > i was hoping for something catchier/more obviously a pun, but excavation isn't bad. Since i currently have no name for it, Fossil Excavator is the first on the list so far. > Hmm all the thoughts before I call it a day. > All very valid, and i apologize profusely for my blatant abuse of the term REST (borne of my ignorance of its details). i'll start removing that word for the time being :). i'm not well-versed in the various semantics of HTTP codes other than 200, 404, and 500, and i have tons of code which currently uses the HTTP 200 + response mechanism to good effect. That's not to say that that's the right approach (that's what the draft doc and these threads are all about), but it's the approach i've been taking so far. i think both models are certainly useful in different contexts, but i don't think the code for both have to be completely incompatible - the error handling changes and some parameter passing, but the payloads (what we're after) can be identical. So it could easily be made an option or even use both: one path uses "my" model and another (/rest/...) uses a strict REST model? :-? PS: you've been added to the doc write list. Feel free to edit. -- ----- 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
