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

Fix parsing #55

Closed
stephencelis opened this issue Jul 21, 2014 · 1 comment
Closed

Fix parsing #55

stephencelis opened this issue Jul 21, 2014 · 1 comment
Milestone

Comments

@stephencelis
Copy link
Member

As it stands, Parser::Simple is, on its own, too simple.

While Endpoint splits responsibility between acceptance and rendering, Endpoint does no such thing between supported media types and parsing.

Why do we need granularity here? Well, the parser supports application/x-www-form-urlencoded and multipart/form-data by default. This seemed like a good idea at a time, but it actually makes Crepe a bit more difficult to step into because the first time you curl-debug, the params you expect to be parsed in from JSON will be nil unless you explicitly add -H "Content-Type: application/json". If it returned early with 415 Unsupported Media Type, it would be a lot easier to debug.

Renderer::Simple supports to_#{format} for any format by default, so we shouldn't need to get rid of form data support, but Renderer::Simple won't get hit at all if the format hasn't been whitelisted. We need the same ability to whitelist supported media types.

Support should be easy, but naming could be hard.

  • .respond_to handles acceptance, but will also shorthand-handle rendering with its **options of accepted formants to renderers.
  • .render handles renderers when Renderer::Simple is too simple.
  • .parse handles parsing.

How do things need to change?

One other thing to look into: do we properly convert application/vnd.name+json to application/json when parsing?

@stephencelis stephencelis added this to the 0.9.0 milestone Jul 21, 2014
@stephencelis
Copy link
Member Author

Closing in favor of #60.

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

No branches or pull requests

1 participant