Geek Answers Handbook

In REST, create a single content type or have separate content types for each resource view?

If I want to follow the practice of using a custom content type for my REST API, I have to define one custom content type for the whole project or define custom content types for each resource view (what is sent to / from my REST API) used in my project?

That is, if I create the Bookstore REST API, where the services say they are in the com.mycompany.mybookstoreapp namespace, create one content type:

Content-Type: application/com.mycompany.mybookstoreapp+xml

Or can I create a content type for each data type that can be sent / deleted via my Bookstore REST APIs?

 Content-Type: application/com.mycompany.mybookstoreapp.user+xml Content-Type: application/com.mycompany.mybookstoreapp.order+xml Content-Type: application/com.mycompany.mybookstoreapp.book+xml
+2
rest
source share
1 answer

Describing the content type for each data seems like the safest solution. If for some reason you want to be compatible with HATEOAS, it will be easier. In the other hand, it makes no sense to have one type of content for everything. Content describes the type for specific data.

About version, you can add version control to your API in three different ways. First, you can add the version number to your URIs, this is an easy way:

 /api/v1/users

Or you can use your new content type:

 application/vnd.acme.user-v1+xml

Or you can also use the qualifier in the Accept header, so you don’t touch your content type:

 application/vnd.acme.user+xml;v=1

It really is up to you. The first solution is easy, but less RESTful than the other two solutions. But these solutions require smarter customers.

+1
source share

More articles:


All Articles