title: Can you help me understand this? "Common REST Mistakes: Sessions are irrelevant"
body: <p>Disclaimer: I'm new to the REST school of thought, and I'm trying to wrap my mind around it.</p>
  
  <p>So, I'm reading this page, <a href="http://prescod.net/rest/mistakes/" rel="noreferrer">Common REST Mistakes</a>, and I've found I'm completely baffled by the section on sessions being irrelevant. This is what the page says:</p>
  
  <blockquote>
    <p>There should be no need for a client
    to "login" or "start a connection."
    HTTP authentication is done
    automatically on every message. Client
    applications are consumers of
    resources, not services. Therefore
    there is nothing to log in to! Let's
    say that you are booking a flight on a
    REST web service. You don't create a
    new "session" connection to the
    service. Rather you ask the "itinerary
    creator object" to create you a new
    itinerary. You can start filling in
    the blanks but then get some totally
    different component elsewhere on the
    web to fill in some other blanks.
    There is no session so there is no
    problem of migrating session state
    between clients. There is also no
    issue of "session affinity" in the
    server (though there are still load
    balancing issues to continue).</p>
  </blockquote>
  
  <p>Okay, I get that HTTP authentication is done automatically on every message - but how? Is the username/password sent with every request? Doesn't that just increase attack surface area? I feel like I'm missing part of the puzzle.</p>
  
  <p>Would it be bad to have a REST service, say, <code>/session</code>, that accepts a GET request, where you'd pass in a username/password as part of the request, and returns a session token if the authentication was successful, that could be then passed along with subsequent requests? Does that make sense from a REST point of view, or is that missing the point?</p>