Feature Request- Strict API endpoint or mode

It would be nice if there were a API endpoint or mode (toggled by client headers?) that would offer an experience that strictly adhered to planned changes.

For example, there is an upcoming change to deprecate unauthenticated GETs (
ACME v2 - Scheduled deprecation of unauthenticated resource GETs)

It’s great that we can test changes like this in staging, but it would be beneficial for many users if we could enable upcoming changes like this in production now. Test systems don’t surface all the edge cases that a production environment does, and it would be a relief to be able to test out the newer APIs in production, while there is still a “lax” API endpoint to fall back on.

3 Likes

Adding:

A versioned API could work on this too:

For example:

  • v2 = the “active” API
  • v2.1 = a first set of future changes
  • v2.2 = a second set of future changes
  • v2.3 = a third set of future changes
  • etc

Instead of waiting for things to break when “v2” updates, users could switch their endpoints to “v2.1”. If all goes well, great. if something breaks on their implementation, we can roll back to “v2” and have many months to work out the problems in production AND (hopefully) document test cases.

2 Likes