Several endpoints in the TRS specification allow requesting a text/plain response rather than the default application/json response. This is currently not implemented for any of the endpoints.
Proposed solution
To implement this, first a generic function investigating the header should be implemented that accepts a list of defined content types for that particular endpoint as well as either all headers or just the Accept header (if available) associated with the request. The function should then inspect the value of the Accept header and compare it to the list of supported content types. If the requested content type is not in the list of supported content types, a BadRequest should be returned. If the header is absent, the default (application/json) should be returned/set. Otherwise, i.e., if the content type specified in the Accept header is among the list of supported types, it should be returned. This function can be used for all endpoints. Then, depending on which validated content type was requested, the Content-Type header of the response should be set accordingly (e.g., if text/plain was requested, the Content-Type header of the response should be set to text/plain).
Possible caveats
It is possible that multiple Accept headers are allowed in a request. If so, content has to be negotiated, i.e., a solution has to be implemented to find the most suitable response for an ambiguous request. One obvious solution is to implement the header validation function described above in such a way that the list of supported content types passed to it is ordered and that if multiple Accept headers are provided, the content type is picked that matches the type in the list that is further at the top of that list. For example, if the client requests either Accept: application/json or Accept: text/plain and the supported content types were passed to the function as ['application/json', 'text/plain'], then the function should return 'application/json', as it has a lower list index thantext/plain. But before implementing it like that, make sure that multipleAccept` headers are indeed supported by HTTP specs.
It might be that [Connexion]() - which is used under the hood in TRS-Filer - will complain if trying to return content types other than application/json. There are some related issues on the Connexion issue board that should be carefully read. For example: https://github.com/zalando/connexion/issues/860 and https://github.com/zalando/connexion/issues/407. There is also this question on Stack Overflow that looks related. If this turn out to be a problem, please post the occurring errors and any other relevant info as a comment to this issue so that we can collaboratively find a solution.
Description
Several endpoints in the TRS specification allow requesting a
text/plainresponse rather than the defaultapplication/jsonresponse. This is currently not implemented for any of the endpoints.Proposed solution
To implement this, first a generic function investigating the header should be implemented that accepts a list of defined content types for that particular endpoint as well as either all headers or just the
Acceptheader (if available) associated with the request. The function should then inspect the value of theAcceptheader and compare it to the list of supported content types. If the requested content type is not in the list of supported content types, aBadRequestshould be returned. If the header is absent, the default (application/json) should be returned/set. Otherwise, i.e., if the content type specified in theAcceptheader is among the list of supported types, it should be returned. This function can be used for all endpoints. Then, depending on which validated content type was requested, theContent-Typeheader of the response should be set accordingly (e.g., iftext/plainwas requested, theContent-Typeheader of the response should be set totext/plain).Possible caveats
Acceptheaders are allowed in a request. If so, content has to be negotiated, i.e., a solution has to be implemented to find the most suitable response for an ambiguous request. One obvious solution is to implement the header validation function described above in such a way that the list of supported content types passed to it is ordered and that if multipleAcceptheaders are provided, the content type is picked that matches the type in the list that is further at the top of that list. For example, if the client requests eitherAccept: application/jsonorAccept: text/plainand the supported content types were passed to the function as['application/json', 'text/plain'], then the function should return 'application/json', as it has a lower list index thantext/plain. But before implementing it like that, make sure that multipleAccept` headers are indeed supported by HTTP specs.application/json. There are some related issues on the Connexion issue board that should be carefully read. For example: https://github.com/zalando/connexion/issues/860 and https://github.com/zalando/connexion/issues/407. There is also this question on Stack Overflow that looks related. If this turn out to be a problem, please post the occurring errors and any other relevant info as a comment to this issue so that we can collaboratively find a solution.