Comments (6)
I think our position here is fairly clear.
from api-guidelines.
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.
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.
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.
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.
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)
- Delete pattern
- State machine pattern HOT 1
- Throttling pattern
- Graph specific HTTP Request/Response
- Shared Type Design Pattern
- HTTP Return Codes don't mention HTTP HEAD HOT 8
- Vanity url is broken with leading slash HOT 2
- Guidance on response payload with 201
- arbitrary JSON pattern/anti-pattern
- Add guidance for pageable post operations
- Fix content table in the main Graph guidelines. merger enum and evolvable enum patterns
- querying arbitrary number of keys in a dictionary insted HOT 1
- Add clarity to expand requirement
- The 'at' naming convention
- Xbox box 360 live
- Vague guidelines about point query support
- Error message localization HOT 1
- Restrictions for openType
- remov sales of all system
- remov cod all
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api-guidelines.