anchor.diff:  * The API will be accessible only by people providing a Facebook OAuth token
   * Each API must have a monitoring / metrics facility
   * Each service may be packaged as a standalone jar, to be run using `java -jar`.
  -* Performance of POST and GET
  -* I will measure the startup time of each server (not that important, but interesting)
  +* On the performance side, I will measure:
  +** request time of POST and GET
  +** the startup time of each server (not that important, but interesting)
  +** the memory footprint of the application
   * Finally, I will give the final size of the package.
   
   == The candidates
  
positive.code: 
  I don't want to make another comparison based on some "Hello World" application. Most of the frameworks provide a simple way to start a server and respond to a simple request with only one line.
  
  But it is not the real life. In the real life, you should not use plain HTTP. You would use REST / HTTPS. You would add headers such as Location after a 201. You add links to your JSON representations. You would have an HTTPS client too. You should have metrics included, to monitor your application. You have some kind of security to protect the access to your API.
  
  Here is a list of what I am going to evaluate.
  
  * I'm about to build a RESTful API. UI is not considered in this article (note that every framework has a mean to serve static resources easily)
  * Only HTTPS to access the API
  * The API will have two sets of resources (aka two microservices). For simplicity's sake, they will be deployed in the same server, but will communicate over HTTPS.
  * The resource will have a JSON representation
  * Each representation will have at least a self link to the resource
  
negative.code: Note that Restlet and Spark doesn't claim to be MicroServices frameworks, but Restlet is known to be a very good REST framework, and Spark is so lightweight that I couldn't resist to try it against bigger frameworks like Spring Boot.
  
  == Dropwizard
  
  
  == Vertx
  
  