Thanks Artemy, 'set' vs 'put' took some consideration. Basically: many
(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,
"memorable" came off as "better": what I meant is "easy to remember".
Thanks Andrew, looking forward.
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at