Feature #1403
REST connections should use content-type for format
| Status: | Closed | Start: | 07/08/2008 | |
| Priority: | High | Due date: | ||
| Assigned to: |  Luke Kanies |
% Done: | 0% |
|
| Category: | plumbing | |||
| Target version: | 0.25.0 | |||
| Complexity: | Medium |
Affected version: | 0.24.4 |
|
| Keywords: | rest, html, http, content-type |
|||
| Votes: | 0 |
Description
Currently, the REST plumbing has yaml hard-coded. This introduces unnecessary overhead for those classes that could be transferred as plain text (e.g., certificates and most files), and it reduces flexibility in providing better language agnosticism.
We need to create some kind of content-type framework that makes it easy to determine whether a given class supports a given content type, and then support built-in HTML content-type handling to select the appropriate type.
History
Updated by Adam Jacob 11 months ago
You likely can look at the source for Merb to get a pretty good idea of how to structure this kind of negotiation. At a minimum, I think you should support:
1) Accept header parsing, with weight preferences. Some working perl code available at: http://search.cpan.org/src/JSHIRLEY/Catalyst-Action-REST-0.62/lib/Catalyst/Request/REST.pm - you should be able to translate the gist to Ruby fairly easily.
2) Direct object serialization via a provides style semantic, a-la Merb. Allow keywords to register for a content-type (say 'application/json' == :json), which corresponds to :to_json and :from_json methods.
In general, have I mentioned that merb rocks this?
Adam
Updated by Luke Kanies 11 months ago
- Status changed from Accepted to Closed
Fixed and merged into master. The only problem is that it doesn't currently use mime types, but that's easy to fix.