URL: SemVer API matching & shorten API path

[jsdelivr]

URL: SemVer API matching & shorten API path

[jimaek]

@bebraw What do you think?
@tomByrer jsdelivr is not redundant, we plan making api.jsdelivr.com a one stop API for all public CDNs out there.
http://api.jsdelivr.com/v1/jsdelivr
http://api.jsdelivr.com/v1/osscdn
...

Thanks for the feedback :)

[tomByrer]

Oh, awesome. Thought of doing the same with a JavaScript... let me dig up bookmarks.
edited above.

[tomByrer]

http://api.jsdelivr.com/v1/jsdelivr
http://api.jsdelivr.com/v1/osscdn

Are these v1 of the master API, or v1 of jsdelivr's API & v1 of of osscdn's API?

[jimaek]

v1 of the master API. I dont think it makes sense to version each API separately. Anyway, @bebraw is the one to decide since its his project :)

[bebraw]

Let's keep it simple for now. Ie. implement all the features we can think of now for v1 and if something comes up, worry about semver then. Introducing it right now wouldn't provide much value as the API doesn't have any users.

I would suggest we leave this issue open, though. But for now I would like to focus on actual use cases for the API and make v1 as nice as possible. I think maintaining multiple versions could easily become a nightmare so we had better do our homework now before things get too much out of hand.

[tomByrer]

maintaining multiple versions

Oh sorry, I assumed you were NOT going to maintain old versions, but bump the version when you make API changes / critical debugs. So:

http://api.jsdelivr.com/v1.0.0/jsdelivr  //release
http://api.jsdelivr.com/v1.0.1/jsdelivr  //first minor bug fix
http://api.jsdelivr.com/v1.1.0/jsdelivr  //API changed

Or do you mean you are not going to host old versions?

[bebraw]

If we want to keep it very simple, we'll make non-destructive changes (ie. new fields and such are ok) on v1. If the schema structure changes in a drastic manner breaking backwards compatibility, we'll bump the number (ie. v2, v3, ...). I don't know if it needs to be more complicated than that.

And yeah, hosting the old versions would be ideal. But let's not overengineer this yet. :)

[tomByrer]

Understood, cheers!

[bebraw]

I'm closing this as we came up with a convention to use.

To recap, non-destructive changes will be implemented for old versions. In case bigger changes are made, that warrants a whole new version (like the upcoming v2).