[GeoJSON] Content-type

Billy Newman newmanw10 at gmail.com
Sun Nov 3 17:03:09 PST 2013


Hello Dret,

'http://tools.ietf.org/html/rfc6839 is an attempt to make this a bit more structured, and then you could use application/geojson+json, making it both clear that it's GeoJSON, and JSON. but this would of course break compatibility with the current practice of using application/json, so maybe it's not such a great idea in the end for things that already are deployed.'

To be 100% honest I am not sure why application/geojson+json would break compatibility.  If you are serving GeoJSON and using application/json and change to server application/geojson+json you are still returning the same thing, in this case GeoJSON.  Isn't application/geojson+json a sub-set of application/json?

Thanks for the great discussion all.

-Billy

On Nov 3, 2013, at 10:35 AM, Erik Wilde <dret at berkeley.edu> wrote:

> hello nelson.
> 
> On 2013-11-03, 09:25 , Nelson Minar wrote:
>> It's too bad that MIME types only describe the encoding and not the
>> actual contents, but that's the way the standards work.
> 
> that's not actually the case. that's the way some communities use them (semweb is one popular example), while others are using them differently. for RESTful web services, for example, many people are minting meaningful media types, instead of using very generic identifiers.
> 
> http://tools.ietf.org/html/rfc6839 is an attempt to make this a bit more structured, and then you could use application/geojson+json, making it both clear that it's GeoJSON, and JSON. but this would of course break compatibility with the current practice of using application/json, so maybe it's not such a great idea in the end for things that already are deployed.
> 
>> The main purpose
>> of that type is to signal the user agent how to decode the thing (ie:
>> it's JSON to turn into Javascript objects, not XML or HTML to turn into
>> DOM or an image or whatever.) It's up to the application to inspect the
>> object contents to determine what was in the JSON blob.
> 
> again, that's a result of designing things in a certain way, and maybe not the best possible one. to me, using profiles actually seems like a pretty good compromise: it's backwards compatible to those who use application/json, but still exposes the fact that the format is more than just generic JSON.
> 
> cheers,
> 
> dret.
> 
> -- 
> erik wilde | mailto:dret at berkeley.edu  -  tel:+1-510-2061079 |
>           | UC Berkeley  -  School of Information (ISchool) |
>           | http://dret.net/netdret http://twitter.com/dret |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20131103/485eb3e8/attachment.htm>


More information about the GeoJSON mailing list