[OSM-dev] PUT /api/0.6/{node|way|relation}/{id|create}

Stefan de Konink skinkie at xs4all.nl
Mon Jun 9 17:02:26 BST 2008


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.

>> - The API more simple (and easier to extend)
> 
> That's debatable - the complexity is simply moved from the client
> having to choose which URL to use to the server having to have
> extra decoding logic.

The logic is already there?

>> - 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.

>> - 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.



Andreas Barth schreef:
> * Tom Hughes (tom at compton.nu) [080609 14:06]:
>> In message <484C8660.4020106 at xs4all.nl>
>>> PUT /api/0.6
>>> {{ Payload }}
> 
>>> - The API more simple (and easier to extend)
>> That's debatable - the complexity is simply moved from the client
>> having to choose which URL to use to the server having to have
>> extra decoding logic.
> 
> I fail to see how using /api/0.6 makes things more complex for now. It
> however *adds* the possibility to keep 0.6 life after 0.7 is productive.
> Or not. That can be decided in future (and old versions of the api will
> definitly break some day, and then be removed).
> 
> But just using /api/0.6 instead of /api should be near zero extra costs
> for now - and if we keep that, or directly remove it on the day 0.7 gets
> activated can be decided when we need to decide it.

Exactly my though; the way I currently have implemented even /api is 
enough, but ofcourse if 0.5/0.6/0.7 is found the server could redirect 
or fall back to an older implementation.


Stefan




More information about the dev mailing list