Versioning in the URL

[dylanmcreynolds]

At the last developers; meeting, we discussed the possibility of changing the version indicator in the enpoint urls from v3 to v4.

I have started playing with the new backend with an eye toward making pyscicat compatible with both the new and old by parsing the url provided to the client and changing the url that gets used for datasets based on the version that pyscicat is talking to. But I currently it's still using v3. If this is likely to change in the future, I'll continue down this path. If not, then I'll find another method to distinguish in pyscicat (probably with an optional parameter in the constructor.)

[dylanmcreynolds]

This was discussed at the developer's meeting again today. Several issues arise. The client autogenerates from the swagger/openapi docs of the server. The current plant is to continue to autogenerate on the loopback version. At a future ti me, this will be swapped to the next.js version.

The version indicator v3 currently describes the loopback version, not the version of our api. We decided that at a future time (probably coordinated with the switch to the client autogeneration) the version indicator will be dropped from the server endpoints.

[stephan271]

I think we will always need the version numbers, in order to help with migration in case of imcompatible changes to the API. In my mind we should not drop it.

[dylanmcreynolds]

At the call this week, I mentioned that there were some possible alternatives to placing the version in the URL path that seem to be gaining traction. Here is a brief summary.

I do not have a super strong opinion here. The path is pretty explicit to developers, which is nice.

[stephan271]

Nice summary. Whatever we choose, we should have the version info "somewhere"

[dylanmcreynolds]

During the scicat meetings, it was decided:

Version number

• url will continue to have a v3 in it
• pyscicat will accept a setup parameter to say "new backend"