Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some unit tests #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add some unit tests #1

wants to merge 1 commit into from

Conversation

jcf
Copy link
Member

@jcf jcf commented Feb 10, 2015

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

@weavejester
Copy link
Member

Yes, so currently there is code to parse the Accept header into a map onto the request, but nothing to then decide which content-type to choose.

My thought was to add an additional utility namespace, ring.util.accept, that would provide a function to pick a content type from a set given a request parsed with wrap-accept. So something like:

(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.

@jcf
Copy link
Member Author

jcf commented Feb 12, 2015

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 util namespace. There's value in simply extracting the accept header alone in middleware.

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 application/vnd.ring.v1+json into a map like:

{: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 ring.util.mime-type…?

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:

@weavejester
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants