On Sat, Jun 12, 2010 at 23:18, Jason Smith <firstname.lastname@example.org>
On Sat, Jun 12, 2010 at 23:13, Paul Bonser <email@example.com>
Ah yes, making it a bit closer to the way that a regular PUT vs. POST
> Why not have these three cases:
> * Document update: doc is something, req.id
> * Document create, PUT to _update/some_id: doc is null, req.id
> * Document create, POST to _update, doc is null, req.is
is a random uuid
> The update function can decide whether or not to honor the "suggested" doc
> id but at least it is now capable of matching the JSON API.
works. What if someone POSTs an ID as part of the _update request?
Return an error telling them that they can only include a doc ID as
part of a PUT?
Wow, when you do it this way, it is just a 1-line patch (attached).
The update function can now do
// To be pedantic, I could confirm req.method == "PUT"
log("I am an update by id");
else if(doc === null && req.id
if(req.method == "POST")
log("I am a create, id was auto-generated");
else if(req.method == "PUT")
log("I am a create, id was supplied by client");
Thoughts? Does this count as an API change? Even if so, I feel like it fixes a bug.
Well, my objective is that it is *possible* for _update to match the JSON API.
Users can POST to _update/some_id with a JSON whose _id doesn't match. A well-written update function would presumably return an error (or whatever straight couch does).