[OSM-talk] Strange api behaviour
immanuel.scholz at gmx.de
Thu Mar 16 11:01:37 GMT 2006
> I would suggest that as the API version number is currently 0.3 that
> it indicates that API is not currently stable. Well... That would be
> my interpretation anyway.
I agree. And unstable may also mean "break immediatly". Steve's response
time to error reports (even on the old API) seems quite good to me. I
don't have any problem here.
>> > With 0.4 I'll introduce some clearer
>> > versioning, so something like /api/current_version will tell you what
>> > to use and each editor can decide what to do.
This seems not necessary to me. If the client implemented the new API, why
should he use the old? And if he only speak the old, he will get 404's
which's fine, isn't it?
>> And either they support the current version, or they say "sorry,
>> current version of OSM not supported". How is that different to now?
The difference is "404 Page not found" versus "The server does not support
this client version".
And it would enable changes, that does not break compability at all (e.g.
adding simple features). However, I prefer not to increment the version
for those changes at all.. (instead, the server should return the
subversion number it is build onto as minor version number). Only change
the URL if you state "incompatible".
I agree with Tom here, the /current_version is not worth it, I think. ;)
>> Why pretend to have an open API at all if you're not going to support it?
What has an "open API" to do with supporting old versions? That we use an
open API means, that everyone can write a client. That the API changes
constantly does not prevent the clients from updating.
However, to address your problem, I suggest using a proxy client which
accept old API's and talk to the server in the new API. This usually works
for most of the cases and if it does not work, then the new API is usually
that incompatible, that supporting any old API would be a very high burden
But it's great for those simple "we renamed uid to id" - stuff.
>> > I'll give a weeks warning announcement so people can update their code
>> > too. As we approach 1.0 this will matter less and less as things won't
>> > change so much.
>> A week isn't going to be long enough.
I think he speak of "a week before the old is shut down", so to say as
"last warning". Not that Steve want to disable old API's every week after
introducing a new version, right? ;-).
>> Unit tests for the current API, before writing the next version, would
>> be a really good idea.
Unit tests for the *new* API before writing it, would be a really good
idea too. ;-)
More information about the talk