A bundle to create quickly a modular REST API upon Symfony 4

Installs: 167

Dependents: 1

Suggesters: 0

Security: 0

Stars: 3

Watchers: 1

Forks: 0

Open Issues: 2


3.1.1 2019-08-27 13:58 UTC

This package is auto-updated.

Last update: 2020-08-11 16:01:52 UTC


php mysql symfony Build Status Stable License: MIT

Table of contents


Philarmony is a bundle made to help you create a modular REST API. From database to controllers and forms, without forgetting authorization and data validation, manage your API easily in minutes.

V.3.0 - What's new ?

Better performances, this is what can resume Philarmony V3. The core has been rewritten with


You can install using composer, assuming it is already installed globally :

composer require deozza/philarmony-core-bundle


In order yo use Philarmony in your project, you need to configure it. First, create a philarmony.yaml file with the following structure :

      entity: ~
      property: ~
      enumeration: ~

This will be used to locate the database schema files. By default they are created and stored in /var/Philarmony/.

Then, to use the embedded services, as the controllers and the repositories, of Philarmony, you need to enable them in your /config/services.yaml and in your config/routes/annotations.yaml :

      resource: '@DeozzaPhilarmonyCoreBundle/Controller'
      tags: ['controller.service_arguments']
      resource: '@DeozzaPhilarmonyCoreBundle/Repository'
      tags: ['doctrine.service_entity']  
    resource: '@DeozzaPhilarmonyCoreBundle/Controller'
    type: annotation
    prefix: /

Finally, in order to use filters inside your query, add the following functions inside the doctrine.yaml configuration file :

                JSON_EXTRACT: Scienta\DoctrineJsonFunctions\Query\AST\Functions\Mysql\JsonExtract
                JSON_UNQUOTE: Scienta\DoctrineJsonFunctions\Query\AST\Functions\Mysql\JsonUnquote

Example of usage

For this example, our API example will manage vacation rentals. Users are able to create rental offers, book vacations and communicate through an internal message service.

Therefore, the database would be constituted with 4 different entity kinds :

  • offer : contains all the infos about a rental offer
  • booking : contains all the info about a booking and the offer it is linked with
  • conversation: contains all the message of a conversation between 2 users
  • message : contains the content of the message and other informations about it

These entities are defined by default inside the entity.yaml configuration file, and their properties inside the property.yaml file.

Here is an example of a cUrl request with its body (in JSON) to create a new rental offer :

curl --header "Content-Type: application/json"
     --request POST
     --data '{"title": "Stunning appartment in Tokyo", "description": "Located in central Tokyo. 2 bedrooms, bathroom, wifi.", "price": 82, "place_category":"appartment"}'

As you can see, the kind of entity you post is specified in the url. This will allow Philarmony to adapt the comportment of the API following the logic you implemented in the yaml configuration files and via your business logic. Here is the JSON response you would expect from the previous request:

  "uuid": "00100000-0000-4000-a000-000000000000",
  "kind": "offer",
  "owner": "00100000-0000-4000-a000-000000000000",
  "date_of_Creation": "2019-01-01T12:00:00+02:00",
  "properties": {
    "title": "Stunning appartment in Tokyo",
    "description": "Located in central Tokyo. 2 bedrooms, bathroom, wifi.",
    "price": 82,
    "place_category": "appartment"

Say that an offer can have multiple descriptions and you want to add another one, simply send a request like the following :

curl --header "Content-Type: application/json"
     --request POST
     --data '{"description": "Animals are allowed"}'

Here will be the expected response :

  "uuid": "00100000-0000-4000-a000-000000000000",
  "kind": "offer",
  "owner": "00100000-0000-4000-a000-000000000000",
  "date_of_Creation": "2019-01-01T12:00:00+02:00",
  "properties": {
    "title": "Stunning appartment in Tokyo",
    "description": [
       "Located in central Tokyo. 2 bedrooms, bathroom, wifi.",
       "Animals are allowed"
    "price": 82,
    "house_category": "appartment"


Response code Raised by Details
200 The request is successful More
201 The post request is successful More
204 The request is successful and the response has an empty body More
400 Form error assertion More
403 User is not allowed to perform this request More
404 The resource requested was not found More
405 The method used is not allowed on the route requested More
409 The request is successful but the data submitted is not valid More

When you perform a request to Philarmony, it will always send a response containing a serialized JSON and one of the HTTP code listed above.

How it works

Database schema

Your database schema is fully designed by 3 yaml files.


An Entity is what could be view as a MySQL table, a main container of data. By default, it is defined by an owner (the User who created the entity), a kind, the date it was create and its properties.


The property is what could be view as a MySQL column, the container of a specific data. By default, it is defined by a type, a unique paremeter and a required parameter.


The enumeration is a list of possible values handled by of property.

Validation state

Validation state is used in order to assert an entity is in good conditions to be used. Each state defines specific methods usable by specific users.


To assure the right user is manipulating a resource, authorization is handled by the validation state. It determines which users are allowed to send the different requests.


In order to pass from one state to the next, the entity and its data must be valid according to constraints.

Conflict rules

A conflict rules is a custom and advanced constraint that need to be developed and cannot be added to a configuration file.


A demo app has been developped and is visible here. Through the tests of this app, we ensure that every feature of Philarmony is tested and we garanty the stability of the bundle.

Road map

  • Database migration : for now, when you delete or update a property or an entity, you need to handle manually the migration. For a better experience, I am thinking about a kind of automatic solution