anchor.diff:  
   https://github.com/blongden/vnd.error[`VndError`] is a popular, de-facto standard mime-type that describes the encoding of errors to the client of a REST service. It works well with errors in the 40x and 50x range of errors. Spring HATEOAS provides `VndError` types that you can use to report errors back to your client. 
   
  -Our revised service introduces a new class, `BookmarkControllerAdvice`, that uses Spring MVC's `@ControllerAdvice` annotation. `@ControllerAdvice` are a useful way to extricate the configuration of common concerns - like error handling - into a separate place, away from any individual Spring MVC controller. Spring MVC, for example, defines the `@ExceptionHandler` method that ties a specific handler method to any incident of an `Exception` or a HTTP status code. Here, we're telling Spring MVC that any code that throws a `UserNotFoundException`, as before, should eventually be handled by the `userNotFoundExceptionHandler` method. This method simply wraps the propagated `Exception` in a `VndErrors` and returns it to the client. In this example, we've removed the `@ResponseStatus` annoation from the exceptio itself and centralized it in the `@ControllerAdvice` type.  `@ControllerAdvice` types are a convenient way to centralize all sorts of logic, and - unlike annotating exception types - can be used even for exception types to which you don't have the source code. 
  +Our revised service introduces a new class, `BookmarkControllerAdvice`, that uses Spring MVC's `@ControllerAdvice` annotation. `@ControllerAdvice` are a useful way to extricate the configuration of common concerns - like error handling - into a separate place, away from any individual Spring MVC controller. Spring MVC, for example, defines the `@ExceptionHandler` method that ties a specific handler method to any incident of an `Exception` or a HTTP status code. Here, we're telling Spring MVC that any code that throws a `UserNotFoundException`, as before, should eventually be handled by the `userNotFoundExceptionHandler` method. This method simply wraps the propagated `Exception` in a `VndErrors` and returns it to the client. In this example, we've removed the `@ResponseStatus` annotation from the exception itself and centralized it in the `@ControllerAdvice` type.  `@ControllerAdvice` types are a convenient way to centralize all sorts of logic, and - unlike annotating exception types - can be used even for exception types to which you don't have the source code. 
   
   
   ## Securing a REST Service   
  
positive.code: 
  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 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.
  
  
  [[maturity-model]]
  
negative.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 for 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 erred 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 
  