media type reality setting in

2007-12-13 @ 23:25#

in the last couple weeks, i worked hard to add solid media-type support to the exyus engine via the Accept header. this results in a good pattern for the GET and HEAD methods. but there's the hitch....

see, i figure a good implementation of multiple media types will need to include possible support for clients to indicate media types for POST and PUT using the Content-Type header. and that will be a bit trickier.

now i need to consider a way to map a media-type list that applies to PUT and POST. it's possible that GET will have more media types than PUT/POST. for example, GET might support Accept:text/plain, text/html, application/atom+xml. but PUT/POST might only support application/atom+xml. i can see lots of cases where PUT/POST will have a much smaller list of supported media types.

now i understand why it is important to constraint the work to the list of media types from the IANA. if i need to code a solid app that supports more than one media type - esp. for PUT/POST, i want to know the standard media types and stick as closely as i can to those.

i guess this is another reason to believe that XML is not a data transfer format!