title: RESTful design for handling requests differentiated as either JSON or multpart/form-data
body: <p>I am designing a REST API for text analysis, and I want to accept submitted content as either JSON or in file format (which is more convenient for large submissions). The JSON format has a "text" field, from which the text is extracted. Uploaded files just contain raw textual content. So I will be handling these two types of content as either a JSON-encoded body, or in the latter case as a multipart/form-data upload. My question is really related to how I should design my API with respect to handling these two different types of submissions, whilst remaining as RESTful as possible.</p>
  
  <p>My initial thought was to have two different endpoints, <code>/json</code> for JSON, and <code>/files</code> for uploaded files. It doesn't seem right, however, to have two endpoints differentiated only by the type of content submitted by clients, rather than functionality. As an alternative I then considered differentiating according to request method, using PUT for JSON and POST for files. Again this seems wrong, since it is add odds with the semantics of the request methods themselves.</p>
  
  <p>It seems the only alternative is to accept the two types of encodings via the same endpoint. I'm still not sure if this is the right way to proceed from a design perspective, however, hence my question. I guess this is precisely what the <code>Content-Type</code> header is for, as stated <a href="https://stackoverflow.com/questions/17681774/rest-input-for-post-can-same-resource-differentiate-between-json-and-xml-input">here</a>. But there seems a more radical distinction between JSON and multipart/form-data than between JSON and XML.</p>