anchor.diff:  
   Dr. Leonard Richardson put together a maturity model that interprets various levels of compliance with RESTful principles, and grades them.  It describes 4 levels, starting at *level 0*. Martin Fowler http://martinfowler.com/articles/richardsonMaturityModel.html[has a very good write-up on the maturity model]
   
  -* **Level 0**: the Swamp of POX -  at this level, we're just using HTTP as a transport. You could call SOAP a *Level 0* technoloogy. It uses HTTP, but as a transport. It's worth mentioning that you could also use SOAP http://www.w3.org/TR/soapjms/[on top of something like JMS] with no HTTP at all. SOAP, thus, is _not_ RESTful. It's only just HTTP-aware.
  +* **Level 0**: the Swamp of POX -  at this level, we're just using HTTP as a transport. You could call SOAP a *Level 0* technology. It uses HTTP, but as a transport. It's worth mentioning that you could also use SOAP http://www.w3.org/TR/soapjms/[on top of something like JMS] with no HTTP at all. SOAP, thus, is _not_ RESTful. It's only just HTTP-aware.
   * **Level 1**: Resources - at this level, a service might use HTTP URIs to distinguish between nouns, or entities, in the system. For example, you might route requests to `/customers`, `/users`, etc. XML-RPC is an example of a *Level 1* technology: it uses HTTP, and it can use URIs to distinguish endpoints. Ultimately, though, XML-RPC is not RESTful: it's using HTTP as a transport for something else (remote procedure calls).
   * **Level 2**: HTTP Verbs - this is the level you want to be at.  If you do *everything* wrong with Spring MVC, you'll probably still end up here. At this level, services take advantage of native HTTP qualities like headers, status codes, distinct URIs, and more. This is where we'll start our journey.
  -* **Level 3**: Hypermedia Controls - This final level is where we'll strive to be. Hypermedia, as practiced using the http://en.wikipedia.org/wiki/HATEOAS[HATEOAS] ("HATEOAS" is a truly welcome acronym for the mouthful, "Hypermedia as the Engine of Application State") design pattern. Hypermedia promtes service longevity by decoupling the consumer of a service from initimate knowledge of that service's surface area and topology. It *describes* REST services. The service can answer questions about what to call, and when. We'll look at this in depth later.
  +* **Level 3**: Hypermedia Controls - This final level is where we'll strive to be. Hypermedia, as practiced using the http://en.wikipedia.org/wiki/HATEOAS[HATEOAS] ("HATEOAS" is a truly welcome acronym for the mouthful, "Hypermedia as the Engine of Application State") design pattern. Hypermedia promotes service longevity by decoupling the consumer of a service from intimate knowledge of that service's surface area and topology. It *describes* REST services. The service can answer questions about what to call, and when. We'll look at this in depth later.
   
   
   [[maturity-model]]
  
positive.code: 
  Of course, sometimes things don't go to plan. Perhaps the browser timed out, or the service has timed out, or the service encounters an error. We've all gotten the annoying 404 ("Page not found") error when attempting to visit a page that doesn't exist or couldn't be routed to correctly. That 404 is a *status code*. It conveys information about the state of the operation. There are http://en.wikipedia.org/wiki/List_of_HTTP_status_codes[*many* status codes] divided along ranges for different purposes. When you make a request to a webpage in the browser, it is an HTTP `GET` call, and - if the page shows up - it will have returned a 200 status code. 200 means `OK`; you may not know it, but it's there. 
  
  * Status codes in the **100x range** (from 100-199) are *informational*, and describe the processing fo the request.  
  * Status codes in the **200x range** (from 200-299) indicate  the action requested by the client was received, understood, accepted and processed successfully
  * Status codes in the **300x range** (from 300-399) indicate  that the client must take additional action to complete the request, such as following a *redirect*
  * Status codes in the **400x range** (from 400-499)   is intended for cases in which the client seems to have errored and must correct the request before continuing. The aforementioned 404 is an example of this.
  * Status codes in the **500x range** (from 500-599)  is intended for cases where the server failed to fulfill an apparently valid request.
  
  ## Building a REST service 
  
negative.code: 
  
  ## Conclusion 
  REST is the most natural way for ubiquitous, disparate clients to communicate. It works because HTTP works. Once you understand how REST fits into an application, it's not hard to envision an architecture with numerous, singly focused APIs all exposed over REST, load-balanced as any other HTTP service would be. It is not surprising, then, that REST (often, but not necessarily) forms a critical foundation for _microservices_, which we'll look at in more depth in an upcoming tutorial. 
  
  
  // TODO: talk about storing Access Tokens in a single store that multiple client nodes use for federated ID in mind. Then show how you can use Spring Boot's auto-configuration approach to share across an organization's services w/ no configuration apart from `@EnableAutoConfiguration`. Show an example of Spring Security OAuth persisting to Redis or something more horizontally scalable than a SQL DB.    
  
  