title: Should API calls be GET or POST?
body: <p>I noticed that some APIs like the Twitter API use get methods for everything, so the parameters are passed in the URL like this:</p>
  <pre><code>http://api.twitter.com/1/statuses/user_timeline.json?screen_name=screenname
  </code></pre>
  <p>I have some questions and would appreciate comments or corrections:</p>
  <ol>
  <li><p>I always thought that using GET is not a good idea, and that it's better to use POST.</p>
  </li>
  <li><p>The API I'm coding requires a key, and I don't think it's a good idea to send it in the URL. So, is it possible to mix both POST parameters and URL parameters?</p>
  </li>
  <li><p>Another problem is that I hear URLs have a max length, so I guess that would make GET out of the way, or is there a workaround?</p>
  </li>
  <li><p>The only problem I'm seeing with POST (and which I'm guessing is why a site like twitter went with GET) is that the request can't be made directly from the browser. Correct me if I'm wrong on this.</p>
  </li>
  </ol>
  <hr />
  <p><strong>Updates: Thanks to everyone who's helping me brainstorm this. I have some updates to clarify some of the comments.</strong></p>
  <ol>
  <li><p>When I was talking about not wanting to send the key in the URL, what I meant is that I don't want the key bookmarked if a user were to bookmark a call, not that I don't want the key exposed at all. So I guess from the answers that I could send it in the header field? Any other options?</p>
  </li>
  <li><p>I want to clarify that when I said POST requests <code>can't be made from the browser</code>, I should have said, <code>POST requests can't be made from the URL</code> as in <code>http://example.com/api/op.json?param=value</code>. Sorry, I misspoke, should have been clearer.</p>
  </li>
  <li><p>Re whether it's RESTful or not: I've done RESTful before with an MVC framework that took care of detecting the verbs and the URLs ended up looking like <code>example.com/entry/1</code>, or <code>example.com/entry/</code> and the HTTP verbs are what controlled the operation being performed (create, update, delete, list). I thought, in a practical sense, that RESTful was most useful for crud-like data (create entry, get entry, update entry, delete entry, show all entries). So if I don't need crud, do I need REST? My question: if a call simply gives input and returns output, does this API need to be RESTful? The URL doesn't look RESTful, so is there something else in the implementation that could make it RESTful?</p>
  </li>
  <li><p>As to the URL size, you commented <code>but if you're seriously concerned about it you probably should rethink your API. GET requests shouldn't be sending that much data to the server.</code> So I have this example: user wants to send a large file. On the server, I won't enter the file into the database or save it (so according to standards I'm not &quot;posting&quot; data), but maybe I'm (these are quickly thought examples, so please take them loosely):</p>
  </li>
  </ol>
  <ul>
  <li>(a) reading the metadata of the file and returning it (should that be GET or POST), or</li>
  <li>(b) I'm reading the metadata and modifying the metada on the file and returning the modified file (should that be GET or POST).</li>
  <li>So this is an example of why I might need to send large data. The question is are (a) and (b) considered GET or POST operations? and this is why I was asking about the URL max length</li>
  </ul>