Giter Site home page Giter Site logo

Comments (6)

garethj-msft avatar garethj-msft commented on May 3, 2024 1

I think our position here is fairly clear.

from api-guidelines.

cleemullins avatar cleemullins commented on May 3, 2024

We had them in for a while, and ended up removing them. After talking with a number of internal teams, we consider the API-In-A-Header to have caused many problems, and actively discourage it's use.

I could be persuaded to put that back in, but in general we kept the guidance "Do this", rather than "Don't do that".

from api-guidelines.

darrelmiller avatar darrelmiller commented on May 3, 2024

There is a big difference between versioning in a custom header and versioning the payload using a versioned media type identifier. Versioning resource interactions using a custom header is full of disadvantages and I would personally never recommend that.

However, attaching a version number to a media type identifier is not a whole lot different to putting a version number in the payload itself, as HTML, XML and many other formats have done for years. Media type versioning has the added feature of being able to conneg versions, which has some value, but I believe is overrated in its utility.

As another point of reference, the upcoming version of OpenApi (fka Swagger) will be using a media type that optionally allows you to specify a media type parameters. e.g application/openapi+json;version=2.0

from api-guidelines.

cecilphillip avatar cecilphillip commented on May 3, 2024

If you don't mind, what are some of these issues exactly? Maybe having a "don't use headers for versioning" section might be helpful

from api-guidelines.

garethj-msft avatar garethj-msft commented on May 3, 2024

As Chris says, we generally try to minimize the negative guidance as opposed to the positive in this document. Header-based versioning (outwith media type versioning) is problematic for a few reasons - it's harder for consumers to store what version they called, proxies and forwarders can easily lose the custom headers. But be aware that this is all a contentious issue and other opinions are very much available. This is just our take on it.

from api-guidelines.

EralpB avatar EralpB commented on May 3, 2024

I would support Media Type Versioning, it should be the future, especially for those in-company APIs, but if you are aiming the public developer audience.. it might be a good idea to use URL versioning since it is easier.
One thing is for sure, just forget about custom header fields :)

from api-guidelines.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.