On Fri, 11 Dec 2009 21:02:52 +0300, Joran Greef <jorangr...@gmail.com> wrote:
> Thanks Artemy, 'set' vs 'put' took some consideration. Basically: many > Javascript APIs use 'get', 'set', 'unset' methods. I used to use POST > (as in 'create') but now find it's easier to deal with network failure > using only PUT (as in 'set') as POST is not idempotent. As mentioned > above, where the server supports PUT, your Http.set would be upgraded > from a POST to a PUT. Where it does not, your Http.set would remain a > POST so you get the best of both worlds. I guess you could do > Http.Get, Http.Post, Http.Put and Http.Delete static methods to get > around 'delete' being reserved. This then is quite extensible, one > downside being that the method names are then upper camelCase. > Although I would argue for point 2 above, I do think that Http.set, > get, unset sits better next to other Javascript APIs. Excuse me if > "memorable" came off as "better": what I meant is "easy to remember". So you propose to use only one of two methods: POST and PUT. This might seem useful in some cases, but any widely accepted library can't do that. Many developers do make distinction between POST and PUT, and library shouldn't decide for them. Also it looks like you think that 'X-Http-Method-Override' automatically makes server think that method wasn't POST. This is not true: I know many cases where you have to implement that manually (and know no case where this is automatic). The only idea I agree with is that such header is better than `_method` parameter. I understand that you want to make ajax calls look more like javascript APIs, however HTTP is quite different from them, and good library shouldn't hide too much from developer. I already know HTTP, and it's *easier to remember* HTTP-like terms, than proposed JS→HTTP mapping. > Re: "Why use 'representation' and not 'body'?" > REST = Representational State Transfer. HTTP RFC says that HTTP message consists of start-line, headers and body. Representation isn't there, sorry. -- arty ( http://arty.name ) -- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
