Type of User Content - Must IANA Register?

I am developing the API as RESTful (although the HATEOAS restriction is not implemented, therefore it is not a REST API as such)

I am a version of the API, and since there are several ways to do this, I think I'm going to use the Accept header. I know alternatives, but the purpose of this question is not to find a suitable way for the API version.

As far as I know, there are two ways to use the API version using the Accept header, as shown here, here and here :

application/vnd.company.myapp-v1+json 

or using a qualifier

 application/vnd.company.myapp+json;v=1 

Although this is perfectly clear, I realized that all x- user content types were deprecated and vnd. Content types must be registered with IANA.

The API is not and will not be public; all clients using it are developed internally.

Writes a custom vnd. is IANA content type required? What happens if the content type is not registered? Can I just use the Accept application/vnd.company.myapp+json;v=2 header even without registering it with IANA?

Since I need a custom content type for conforming content for version control purposes, can I use a qualifier like application/json;v=2 ?

+7
rest mime-types
source share
1 answer

From what I can read from https://tools.ietf.org/html/rfc6838#section-3.2 , this is optional, however if you have an API that is publicly available do it.

RFC6838 is dedicated to registering new MIME / Media types, with the following text, this does not seem to be a problem for a private API (product)

The vendor tree is used for media types associated with the public use of available products.

Also, this is not required for a public API (product), as I said it is recommended.

While publishing and viewing media types should be registered in
vendor tree is not required using media-types@iana.org
A mailing list for review is recommended to improve the quality of these specifications. Registration in the vendor tree can be done submitted directly to the IANA, where they will go through the Peer Review [RFC5226] prior to approval

+1
source share

All Articles