Current articles

REST api: the MADO's way


"Hypermedia as the Engine of Application State (HATEOAS) is a constraint of the REST application architecture that distinguishes it from other network application architectures.". With Symfony and few bundles it is possible to build good REST api. But how to present data? HATEOAS is the main choice actually. Myabe not the best one. An hypermedia api contains self descriptive links. It helps who build frontend di easy find right links. This is the reason I like hateaos. And also the reason I love standards: who build the client already know how to "read" responses and removes time to explain how could work the wheel. This format contains data (a single item or a collection) and self-descriptive link. Is the format we chosed for our apis.


In symfony there is a good bundle to work with HATEOAS. Its name is BazingaHateoasBundle.

Another fundamental tool for authentication api is jwt. We use LexikJWTAuthenticationBundle. Its easy to install and provide a good jwt authentication.

And sure!!! We also unse FOSRestBundle.

    composer require jms/serializer-bundle
    composer require willdurand/hateoas-bundle
    composer require white-october/pagerfanta-bundle


BazingaHateoasBundle provide a good tool to present data. But to present data we need to make powerful queries. We do this using some snippet of code bundled inside an open source project. We started to build doctrine's queries dinamically from smart querystring. Before simple id like /api/resource/{id}. After with complex querystring like /api/resource?filtering[name|list]=Simone,Alessandro. A lot of application do this kind of queries. We move the logic inside a BaseRepository and our QueryBuilder. The result is the possibility to query the database retrieving custom information without writing any single line of doctrine's code.


We are able to query qith three group of statements:


  • eq
  • gt
  • gte
  • lt
  • lte
  • neq


  • endswith
  • notcontains
  • contains
  • startswith


  • field_eq
  • list


Before the creation of query-bundle the creation of api was very annoying and took a huge amount of time. Now this operation take few minutes. I've also found the way to solve bug and other issues between projects. This is the good news. The bad news is that the query-bundle needs love to be covered with tests and so on. Is high value code for us. But we need to work hard to remove unreadable code and hard to maintain code. We are working on version 1.0 to fix all issuess.