title: REST API - file (ie images) processing - best practices
body: <p>We are developing server with REST API, which accepts and responses with JSON. The problem is, if you need to upload images from client to server.</p>
  
  <p>Note: and also I am talking about a use-case where the entity (user) can have multiple files (carPhoto, licensePhoto) and also have other properties (name, email...), but when you create new user, you don't send these images, they are added after the registration process.</p>
  
  <hr>
  
  <p>The solutions I am aware of, but each of them have some flaws</p>
  
  <p><strong>1. Use multipart/form-data instead of JSON</strong></p>
  
  <p><em>good</em> : POST and PUT requests are as RESTful as possible, they can contain text inputs together with file.</p>
  
  <p><em>cons</em> : It is not JSON anymore, which is much easier to test, debug etc. compare to multipart/form-data</p>
  
  <p><strong>2. Allow to update separate files</strong></p>
  
  <p>POST request for creating new user does not allow to add images (which is ok in our use-case how I said at beginning), uploading pictures is done by PUT request as multipart/form-data to for example /users/4/carPhoto </p>
  
  <p><em>good</em> : Everything (except the file uploading itself) remains in JSON, it is easy to test and debug (you can log complete JSON requests without being afraid of their length)</p>
  
  <p><em>cons</em> : It is not intuitive, you cant POST or PUT all variables of entity at once and also this address <code>/users/4/carPhoto</code> can be considered more as a collection (standard use-case for REST API looks like this <code>/users/4/shipments</code>). Usually you cant (and dont want to) GET/PUT each variable of entity, for example users/4/name . You can get name with GET and change it with PUT at users/4. If there is something after the id, it is usually another collection, like users/4/reviews</p>
  
  <p><strong>3. Use Base64</strong></p>
  
  <p>Send it as JSON but encode files with Base64.</p>
  
  <p><em>good</em> : Same as first solution, it is as RESTful service as possible.</p>
  
  <p><em>cons</em> : Once again, testing and debugging is a lot worse (the body can have megabytes of data), there is increase in size and also in processing time in both - client and server</p>
  
  <hr>
  
  <p>I would really like to use solution no. 2, but it has its cons... Anyone can give me a better insight of "what is best" solution?</p>
  
  <p>My goal is to have RESTful services with as much standards included as possible, while I want to keep it as simple as possible.</p>