Symfony Rest Beer Edition (Work in progress)

Welcome to the Symfony Rest Beer Edition!

Features in this application:

• Specific HTTP Status Codes (204, 206, 400, 404...), HTTP Verbs (GET/POST/PUT/DELETE/OPTIONS)
• Routes with subresources, collection filters...
• Fully swagger documentation (visit /api/doc)
• Symfony's Form component support
• Routes pluralization (beer -> beers & brewery -> breweries).
  See class ApiBundle\Util\Inflector\BreweryInflector.
• Serialization exclusion strategies
• HATEOAS with exclusions policies - use Hypertext Application Language (HAL)
• Support JSON/XML format

Installation

1. Update parameters.yml (create a new secret key)

2. Execute this commands

   composer install
   php app/console doctrine:database:create  
   php app/console doctrine:schema:create  
   php app/console doctrine:fixtures:load -n
   

3. Check configuration by executing php app/check.php

4. Test composer test

What's inside?

• All Symfony default bundles (FrameworkBundle, DoctrineBundle, TwigBundle, MonologBundle...)
• JMSSerializerBundle - Easily serialize, and deserialize data of any complexity (supports XML, JSON, YAML)
• FOSRestBundle provides several tools to assist in building REST applications
• BazingaHateoasBundle provide HATEOAS
• NelmioApiDocBundle provide a nice documentation for API (inspired by Swagger UI project)
• NelmioCorsBundle adds CORS headers support in your Symfony2 application
• DoctrineFixturesBundle provide breweries and beers (see Maxpou\BeerBundle\DataFixtures\ORM\LoadBeersData.php)

And in /src :

• ApiBundle : contain API controllers
• MaxpouBeerBundle : contains entities, forms, fixtures and back office controllers
• AppBundle : Back office controllers... not very important!

Back-office views use Bootstrap (CDN Host)

Focuses

Entities:
We have only 2 entities: Brewery and Beer (Many-To-One relationship).

Code First approach:
I use Code First approach (by opposition to Database/Model First). It's mean that I start by writing classes not model/SQL DDL orders. Otherwise it's hard to maintain (I know, doctrine is reverse engineering compliant).

UUID:
Prefer UUID instead of auto increment because, it's make harder to discover existing resources (for malignant users). Also, it's might not be unique in distributed systems.

TODO

REST misconfiguration:

• POST /whatever-collection... -> must return HTTP header: Location: http://app.com/breweries/newidcreated
• GET /whatever on array objects, Only put URI
• GET /whatever-collection -> must return HTTP code 206 (Partial content) and add links into Link HTTP headers (e.g. fist, prev, next and last page)

Enhancements:

• Make controllers more thins! (use ParamConverter, avoid doctrine researches in controllers)
• Implement PATCH HTTP method
• Exclusion strategy: allow HTTP header Prefer/Vary (Request) and Vary/Preference-Applied (Response). Because clients don't need the same information
• Allow sort collection
• Add a /serve API to implement HTTP Rate limitation.
  HTTP Headers:
  • X-RateLimit-Limit: Total number of beer allow to drink ;)
  • X-RateLimit-Remaining: Beer left
  • X-RateLimit-Reset: remaining window before rate limit resets (UTC epoch seconds)