The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner. The
value in this field is called a media type.
HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.
The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.
I suggest either model/3dm or model/vnd.3dm based on a quick review of the information. My understanding is that the vnd prefix is suitable for commercial/proprietary types. The 3dm file format is proprietary, but the tools for reading and writing it are open source. I've used model/vnd.3dm in the examples below.
A couple of examples, based on my understanding of why this is useful...
The client calls the server's /export endpoint with the Accept header set to model/vnd.3dm. The server responds by exporting a saved model as a 3dm file and returning the binary data in the response body. The server could also support model/stl and model/obj.
The client calls the server's /convert endpoint with a Content-Type: model/stl and Accept: model/vnd.3dm and the contents of a binary STL file in the request body. The server returns a 3dm file in the response body that contains a mesh that was created from the STL file.
I'm unsure if there should be special considerations for sending and receiving 3dm blobs (i.e. the serialised opennurbs geometry data that compute deals with). Perhaps for this we should use model/vnd.3dm+json, as per RFC 3023.
We may need to register something, at some point. For now I'm just taking notes!
Based on a question from ShapeDiver on the forum...
http://tools.ietf.org/html/rfc2045#section-5
I suggest either
model/3dm
ormodel/vnd.3dm
based on a quick review of the information. My understanding is that thevnd
prefix is suitable for commercial/proprietary types. The 3dm file format is proprietary, but the tools for reading and writing it are open source. I've usedmodel/vnd.3dm
in the examples below.A couple of examples, based on my understanding of why this is useful...
Accept
header set tomodel/vnd.3dm
. The server responds by exporting a saved model as a 3dm file and returning the binary data in the response body. The server could also supportmodel/stl
andmodel/obj
.Content-Type: model/stl
andAccept: model/vnd.3dm
and the contents of a binary STL file in the request body. The server returns a 3dm file in the response body that contains a mesh that was created from the STL file.I'm unsure if there should be special considerations for sending and receiving 3dm blobs (i.e. the serialised opennurbs geometry data that compute deals with). Perhaps for this we should use
model/vnd.3dm+json
, as per RFC 3023.We may need to register something, at some point. For now I'm just taking notes!
References
Examples
model/stl
model/obj
model/gltf+json
model/gltf+binary