Add some unit tests#1
Conversation
|
Yes, so currently there is code to parse the My thought was to add an additional utility namespace, (accept/content-type request #{"text/plain" "application/json"})
=> "application/json"The reason for splitting it up in this way is because the list of allowed content types may change depending on the resource being accessed. I'd be interested in knowing your opinion. |
|
Hey James, Quick dump of my thoughts before I have to head off for the weekend. I think handling 406 responses and alike makes sense in a The question for me is how much work should the library do. At what point does the application author need to start processing the accept header, and should we do more with parseable MIME types? For example, should ring-accept parse accept headers of the form {:vendor "ring"
:version "1"
:suffix "json"}Should we simply return the string and expect the user to do the rest? If there was to be some MIME-type parsing it might make more sense in the existing Could you share your thoughts on the features this library should provide? With that information I think the rest will fall into place. Some existing libraries and projects I've looked at: |
|
I think parsing mime/media types should be left for another library. The HTTP spec has little to say on the subject, and it seems a reasonable place to draw the line. Media type parsing also sounds like it would be useful in many places outside of ring-accept, so IMO it would make more sense as a separate project. |
Hey @weavejester. I recently found myself parsing accept headers in an application, and wanted to use ring-accept to accomplish the task.
I can see the library is a work in progress, so I've stopped work in favour of a quick conversation about any plans you might have.
From what I can tell there's something to work out around ordering lists of accept headers, and potentially parsing version numbers and content types in headers of the form
application/vnd.ring.v1+json…