Tom Hughes schreef: > In message <[EMAIL PROTECTED]> > Stefan de Konink <[EMAIL PROTECTED]> wrote: > >> Tom Hughes schreef: >>>> The proposed change makes: >>>> - The QUERY_STRING to be irrelevant >>> It already is. No current API request uses QUERY_STRING. >> Then make the query string irrelevant. > > I repeat myself. The query string is already irrelevant.
Steve: > it doesn't, toms point (which I agree with) is that it shifts >> > complexity to the server (and I further think this is a bad thing) So *remove it from the specs*! If you don't depend on it. PUT /api/0.6 would be enough right? >>>> - Reduces the amount of requests >>> Why is that good? >> Because for every request a new process is forked, thus handling more >> data in one request will reduce the load of the webserver frontend. >> Hence also reducing memory footprint for updates. > > The current architecture does not fork for each request, and I can't > see that any plausible new architecture would. > > Support for multiple updates in one request is already a feature of > the 0.6 API in the form of the diff or changeset upload. Different function. Same problem, same implementation. >>>> - Assures the client always get the id back >>> That is already assured by the current API definition. >> For 'updates' too? According to spec only an id is send after a create. > > Well you don't need it on an update as you already know the ID. Not if you create a changeset with updates and creates. Should the client maintain which object was a create and which one was an update? Now that sounds like making it difficult for the clients, instead of just returning all id's in the diff/changeset. Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev