Re: [Rails-core] Custom accept headers
105 views
Skip to first unread message
Steve Klabnik
Oct 31, 2012, 10:50:26 AM10/31/12
to rubyonra...@googlegroups.com
> Shouldn't Rails coerce these new almost standart headers to application/json
> and applicatioin/xml (for previous example) ?
No, because 'application/vnd.foo-v1+json' is not 'application/json.'
The "+foo" convention was actually introduced in RFC3023, specifically
for XML formats. But it's only a convention, as the RFC says:
> A.13 What is the semantic difference between application/foo and
> application/foo+xml?
>
> MIME processors that are unaware of XML will treat the '+xml' suffix
> as completely opaque, so it is essential that no extra semantics be
> assigned to its presence. Therefore, application/foo and
> application/foo+xml SHOULD be treated as completely independent media
> types. Although, for example, text/calendar+xml could be an XML
> version of text/calendar[RFC2445], it is possible that this
> (hypothetical) new media type would include new semantics as well as
> new syntax, and in any case, there would be many applications that
> support text/calendar but had not yet been upgraded to support
> text/calendar+xml.
Making it work with respond_to :"vnd.foo-v1+json" seems fine, though.
> and applicatioin/xml (for previous example) ?
No, because 'application/vnd.foo-v1+json' is not 'application/json.'
The "+foo" convention was actually introduced in RFC3023, specifically
for XML formats. But it's only a convention, as the RFC says:
> A.13 What is the semantic difference between application/foo and
> application/foo+xml?
>
> MIME processors that are unaware of XML will treat the '+xml' suffix
> as completely opaque, so it is essential that no extra semantics be
> assigned to its presence. Therefore, application/foo and
> application/foo+xml SHOULD be treated as completely independent media
> types. Although, for example, text/calendar+xml could be an XML
> version of text/calendar[RFC2445], it is possible that this
> (hypothetical) new media type would include new semantics as well as
> new syntax, and in any case, there would be many applications that
> support text/calendar but had not yet been upgraded to support
> text/calendar+xml.
Making it work with respond_to :"vnd.foo-v1+json" seems fine, though.
Richard Schneeman
Oct 31, 2012, 11:12:37 AM10/31/12
to rubyonra...@googlegroups.com
A. S
On Wednesday, October 31, 2012 at 6:37 AM, Christopher COCCHI-PERRIER wrote:
Hi,Currently I see many applications using custom accept headers for their API versionning such as application/vnd.foo-v1+json or application/vnd.bar-3+xml. But when Rails receive such an accept header, it cannot convert it to a standart Mime::Type and thus causing problems errors when using `respond_to` with :json or :xml.And Mime::Type#register only allows to register string not regexp, so it is not convenient when coming to versionning.
Shouldn't Rails coerce these new almost standart headers to application/json and applicatioin/xml (for previous example) ?
If you think this should goes into Rails, I'd be happy to provide a pull request.Cheers,--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/CubR52aCYWcJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Richard Schneeman
Oct 31, 2012, 11:15:12 AM10/31/12
to rubyonra...@googlegroups.com
S w mill wxswcsswxe ce cxssxsqseaxqxxqs six desssssqssssssx. W ce cedsdc cx dA
Richard Schneeman
Oct 31, 2012, 11:16:49 AM10/31/12
to rubyonra...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages