Add support for multiple api versions

[marcelklehr]

I'm not sure, whether this is the right way to do this, perhaps there should be multiple implementations of 'node/db/API.js' (one for each API version).

Anyway, if this is the right way, someone should add a comprehensive list of all the API endpoints that are supported by API version 1 (I haven't got time for this, atm) -- that's why I pushed it to Pita's repo...

EDIT: I've had time to do this, just now...

[marcelklehr]

I chose to tag the first version of the API (as it was in etherpad lite v1.0.0) as v1, which will probably break very much existing stuff, outside of etherpad lite core.

We could leave the API as it is (with all endpoints,that currently exist, added to it) tagged as v1, but then it doesn't make sense, to bump the version, now, IMO...

Comments are welcome :)

[marcelklehr]

I still feel that this patch is a useful addition, even if we don't bump the version now... (It'll just need some minor changes in this case.)

[JohnMcLear]

I'm pro this patch but I'm not in a position to approve/disagree with the pull request. I want someone w/ more experience of recently working w/ the API to share their thoughts :)

[jhollinger]

I'm pro a patch very much like this. Different files for different versions may be a good idea, at least after there are enough versions.

My concern is that this will break clients. IMHO everything that was "officially" released under v1 of the API should remain in v1. Also, I don't think the API versions need correlate with the overall version, which looks like what this is attempting.

Adding backwards-compatible functionality to an existing API version, which is what we've been doing, may not be the best thing. But it's far better than breaking external API compatibility. See the recent spat between Linux Torvalds and Miguel Icaza...

[marcelklehr]

Also, I don't think the API versions need correlate with the overall version, which looks like what this is attempting.

@jhollinger Nope, that was not my intention, but I agree to leave the API version at v1 for now, 'cause we didn't introduce any breaking changes on the endpoints of the first release, since then, all clients should be compatible.

The only thing that's troubling me is, people with older installations might try to call one of the younger endpoints and get an error, although it's the same API version. But I guess, it's better this way, than the other way 'round...

I just updated the patch and it should now be 100% backwards compatible, since it only introduces some conceptual adjustments, so new API versions should be quite simple to release.

[JohnMcLear]

Just to confirm, this wont break any current existing functionality/API request/responses will it?

[marcelklehr]

There's always a chance of making a mistake, but I adjusted the existing implementation very carefully, so it should not, really!