Check for content types accepted by client

[uniqueg]

API endpoints can serve different content types, e.g., application/json, text/plain etc. Clients can ask a service to respond with one or more specific accepted content types.

It would be nice if FOCA implemented a solution (e.g., a decorator) that compares the client's desired content type(s) against the ones that the service offers for the respective endpoint (as defined in the API specs). An appropriate error response should be returned if a client requests a content type that the endpoint cannot deliver. If the client does not explicitly ask for a specific content type (i.e., if the Accept: <content-type> header is missing), the default response should be given.

Other important points to think about:

• Connexion may already take care of validating Accept headers to some extent; on the other hand, it may also be the case that Connexion will complain if JSON-incompatible content types are to be returned
• It needs to be checked how content is negotiated between client and server, especially in situations where the client/server accepts/offers multiple content types

[vipulchhabra99]

Can I take up this issue next?

[anuragxxd]

@vipulchhabra99 are you working on this? Or may I please take the issue.

[uniqueg]

Oh, I didn't see @vipulchhabra99's comment, sorry about that. From my side it's okay for either of you to take up that issue

[anuragxxd]

I am working on it.:)

[vipulchhabra99]

It's fine @uniqueg, I haven't started working on it.

[anuragxxd]

@uniqueg In this we have to take user input for each specific route or the whole app. I think it's for the whole app.

[uniqueg]

I'm not sure I understand your question, but the goal here would be to create a generic solution for a relatively common problem - content negotiation between client and server. If the client requests the response to be of one or more specified content types (via the Accept: <content-type> header), the server SHOULD return the response in one of the requested content types, if it can, or else return an appropriate error response, probably 406 Not Acceptable.

To implement that, I had thought of defining a decorator that handles the content negotation and that could be added to the controllers of every specific route. But I can see that at least in most cases (I currently can't think of examples that would not want to have content negotation activated, but cannot rule out that there are not) it would be useful to have this for all routes. But I'm not sure how to implement that, given that FOCA doesn't have direct access to the routes. If you find a way (e.g., via Connexion) to do that globally, for the entire app, that would be awesome! In that case, I think we should go for such a solution and only implement a route-based solution if anybody actually asks for that.

As a starting point, please have a look at the issues linked in the issue description to find out what Connexion already has supported, what the limitations are etc. There may be other relevant issues in Connexion as well. Please post any findings, with relevant links (ideally to definite information such as code, specs etc) in this issue so that we can review them together before deciding on an implementation strategy.