title: How to send larger amounts of data to a stateless RESTful retrieval service
body: <p>This seems quite a basic question so apologies if this has been asked before; please point me in the direction of any useful resources.</p>
  
  <p>So I have a RESTful service to retrieve some data. However, the RESTful service requires a certain amount of data in order to do the retrieval. This data could be roughly summed up as "user context" data - information about the user (whether stored by the calling application or previously retrieved from another application) which the service needs to use to action the retrieval.</p>
  
  <p>Since REST works semantically, the correct verb (HTTP method) to retrieve something is a GET request. Most example GET requests I have seen only use small amounts of data, and the data is passed on the URL. However once we get into the realm of services which require larger amounts of data to make the retrieval, it seems wrong to put all that information in the URL. Not only that, but there are known limits to URL length enforced by certain components (often 255 characters or so, IIRC).</p>
  
  <p>Seemingly the options available are:</p>
  
  <ul>
  <li>Use POST to send the data in the request body. However, this is not semantic since we are not asking the service to update anything, only retrieve.</li>
  <li>Put the larger portion of information (in my case, the "user context") into an HTTP header. However, this "feels wrong" as headers should be used for headers, not data.</li>
  <li>Make multiple requests to send the data in multiple URLs. However this seems to break the stateless goal, as the service would have to maintain some kind of state to tie the requests together.</li>
  <li>Write the data to a database and then pass the service a key to retrieve the data from there. However this would result in the request not being self-contained and also introduce performance bottlenecks.</li>
  </ul>
  
  <p>Is there another option? What's the best practice here?</p>