There are at least two different dialects of geospatial JSON1 data on the internet today and we're doing very little to explain to clients or servers which one is being used in a particular interaction. A web API may return data using the application/json media type if given a f=json parameter (or not) but a client doesn't necessarily know whether it is getting GeoJSON2 or ArcGIS JSON3, two different ways of structuring information about the same kinds of entities.
What's a 'profile'? I'll quote from draft-wilde-profile-link-034:
The concept of a profile has no strict definition on the Internet or on the Web. For the purpose of this specification, a profile can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics. A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. While this specification associates profiles with resource representations, creators and users of profiles MAY define and manage them in a way that they can be used across media types and thus could be associated with a resource, independent of its representations (i.e., using the same profile URI for in different media types). However, such a design is outside of the scope of this specification, and clients SHOULD treat profiles as being associated with a resource representation.
The 'profile' Link Relation Type I-D5 drafted by Erik Wilde can help us serve GeoJSON along with all the special semantics entailed in that spec (default coordinate system, meaning of the 'properties' object, etc) with less ambiguity. As discussed in Mark Nottingham's blog6, it may also provide a way to formalize extension of GeoJSON. If the GeoJSON profile were http://example.com/profiles/geojson-org, an extension that layered, for example, data series semantics7 over GeoJSON might say that the http://example.com/profiles/data-series profile extended http://example.com/profiles/geojson-org.
(I've deliberately not used a profile URI under http://geojson.org in the examples above and proposal below so as to not trigger premature implementation.)
A single profile identified by http://example.com/geojson.org-profile will signal the presence of all the extra semantics that the GeoJSON adds to the application/json media type defined in RFC 46278. Servers that want to provide this signal to distinguish GeoJSON from other JSON dialects can add a link header to response like so:
HTTP/1.1 200 OK
Content-Type: application/json
Link: <http://example.com/profiles/geojson-org>; rel="profile"
Connection: close
{
"type": "FeatureCollection",
"features": [...]
}It's possible that a JSON document returning just a GeoJSON feature outside of a collection, or just a geometry outside of a feature, might be said to be using a different profile of GeoJSON.
just as an update, the "The 'profile' Link Relation Type" draft now has been published as RFC 6906.