Accept header support for Content negotiation

[saini-prakhyat]

Currently GoFr determines the Content Type of response based on the Content type of the request header as mentioned here. As per the HTTP guidelines this behaviour is determined by the Accept header. The question here is that if GoFr wants to carry on with the current behaviour or will it want to support content negotiation using Accept header.

[aryanmehrotra]

By default, GoFr sets it based on the request content-type. Moreover, it gives option to change by returning the following type from handler.
The decision of what has to be returned is upto the user, where gofr only keeps the default content-type as request content-type.
https://github.com/gofr-dev/gofr/blob/development/pkg/gofr/types/rawWithOptions.go

[saini-prakhyat]

Okay understood but if a server has the capability of responding in both JSON and XML , in that case setting the content type using handler hard bounds an API to a particular response type. Moreover in case of GET request it does not make sense to send a content type header. That's why I suggested that content negotiation for response content type should be done based out of Accept header.

[aryanmehrotra]

@vikash we would need your opinion on this.
As per the HTTP documentation, response header choice should be given in the request.
Right now, in GoFr it is completely decided by how it is implemented at the server side and the client cannot change it by specifying the Accept headers.

IMO, Its a good feature but considering it would create a lot of options for client to get data in, as its not just about content-type but its about image type, encoding, compression etc. It would also create a lot of issues from client side depending on what different browsers support and if it has not been properly implemented at client side.
With current implementation the response is pretty much predictable.

Why not content-negotiations : https://wiki.whatwg.org/wiki/Why_not_conneg