Code reuse proposal: API-CRUD – Create Read Update and Delete for data management

posted in: Standards | 0

What do we need?

  1. tools that make it easy to create a ReST API
  2. structure that separates concerns e.g. domain from infrastructure and model from control
  3. consistency – so we can easily maintain many projects from many authors
  4. minimise technical debt – have bulk of the code come from peer reviewed sources e.g. open source framework

What do we want?

  1. code that writes itself with guidance from us
  2. code that works everywhere
  3. code that is clear and concise
  4. code structure that mirrors the problem it solves

PHP REST API Frameworks

I looked at ReST API implementations and found four implementations that I think are valuable:

  1. ArrestDB –
  2. Silex ReST –  Tutorial here.
  3. Symfony ReST –
  4. CodeIgniter ReST –,, and with
  5. Apigility —
  6. iRESTFUL —
  7. Spire — if you gave irregular data, MongoDB is a good choice and  Spire provides a ReST API to front it.
  8. Slim Mongo Rest —
  9. Spray is an open-source toolkit for building REST/HTTP – good for concurrent solutions (where scale is the key driver) and embedded systems (where simplicity is the key driver).
  10. Install the Voryx REST Generator bundle and compare it to symfony-rest-edition.
  11. Skinny framework offers exactly what we need from a response and scaffolding experience point of view. Now my personal favourite.
  12. The Doctrine 2 REST server and client component is both an easy way to spin up REST services for your Doctrine 2 entities as well as a way to work with REST services via an ActiveRecord style implementation similar to ActiveResource in Ruby on Rails!
  13. This library allows you to quickly/simply generate an API for your application by annotating your entities into RESTful resources. It comes shipped with it’s own internal router, and can be used standalone or alongside your existing framework stack. Routes are mapped to either a default or customised service action that takes care of handling requests.
  14. DataBeam Dynamically generate RESTful APIs from the contents of database tables or CSV files. Provides JSON, XML, CSV, and HTML output and auto generated documentation.
  15. Symfony2 REST API: the best way – – Repo
  16. DreamFactory is an open source mobile backend that provides RESTful services for building modern applications.
  17. A simple but incredibly useful REST API server for MongoDB using Node, using Express and the native node.js MongoDB driver.

Other projects I found intersting are and

Other reviews:

[5] The most promising “new kid on the block” currently in version 0.9.1 is created by none other than the Zend team. Download the 1.0.0beta1 version of Apigility 26 March 2014.

[6] The most interesting new development is repo at

Proposal: Use [1] [5] or [12] or [13] or[14] to begin a project and hopefully never look back. Use [1] if  [5] does not work or [2] to finish and maintain a current php app if 3 or 15 is too difficult, and use [3 or 15] to build a modular code base with re-use potential in the future.

The ideal is to use [3 or 15]. Symfony provides the right architectural approach to support our long term goals. Its echo system helps minimise technical debt and build on a solid foundation. Do Symfony with [15].

If you are in a hurry and still want to leave a maintainable api behind, use [2]. Silex Rest is up to date and built on a solid foundation. Its geeky enough and will appeal to the hipsters. Its solid enough to get the nod from the engineers and its lean enough to match well to the ReST API task. Its modularity is self imposed and its generator has some more room for development. Even front-end developers will be able to get it up and running in a flash.

If you are starting out an AngularJS project and only need table based persistence, I think [1] is a viable option. Its a drop in file which you connect to your DB, and that is it. For POC and early development work, or even if you want to accelerate the delivery of the part the customer sees, ArrestDB is my choice for backend API until it cannot do what the client is requesting. Then is the right time to swap it out with something like Silex ReST or Symfony ReST.


1. ArrestDB

ArrestDB – https:/ is an expanded fork of Arrest-MySQL –

ArrestDB is a “plug-n-play” ReSTful API for SQLite, MySQL and PostgreSQL databases.

ArrestDB provides a ReST API that maps directly to your database structure with no configuration.


  1. Instant working single table access ReST interface. Great for front end developers who want persistence on their own LAMP server.
  2. SQLite, MySQL, PostgreSQL


    1. No MSSQL support
    2. No API KEY or security support

2. Silex ReST

Silex-Skeleton-Rest – is a fork of with added scaffolding tool


      1. Its modular structure support our “Domain Driven Design” approach.
      2. It runs on Silex which is a native composer type framework.
      3. Symfony libs are the foundation.
      4. Scaffolding tool is custom but ITE standards compliant.
      5. Implements Doctrine DB migrations.


      1. Naive scaffolding implementation – not battle hardened.
      2. Silex is very flexible. Unlike Symfony where modularity is strongly enforced through the bundle architecture.
      3. Home brew solution that will require our time to make it better. We become responsible for it.


3. Symfony ReST

Symfony Rest Edition – is a fork of – —

It is a template ReST API  implementation. The 2.3 branch runs on Symfony Long Term Support version.

From a CTO perspective Symfony is the right foundation for Enterprise Software development. It is like the Spring Framework in the Java world. All the concepts match. Its native Modular Architecture in the form of bundles is the most important feature that contributes to a mature codebase as projects come and go. Why Symfony.


      1. The right foundation for full stack PHP but maybe overkill for ReST.
      2. Great ReST implementation.
      3. All the goodness of Symfony. It all fits together so well.
      4. Active development, keeps it current.


      1. Steap learning curve.
      2. No ReST API scaffolding or module generation.
      3. We are not part of the Symfony “community of practice”.


4. CodeIgniter:

If we want to stick to CodeIgniter which is currently our back-end and full stack PHP framework, there are 4 options.

1.1 The first option is to simply use Phil Sturgeon’s ReST server – which I implemented in this repo to test –

It works really well and we implemented it in the Water Information Management System –


      1. We found that AngularJS could POST to this ReST Server even tough Apache cannot populate the $POST with an Angular $ payload.
      2. It has a API Key feature to secure access to the endpoint.
      3. We already use CodeIgniter and know how to configure it for MSSQL and MySQL implementations.
      4. We added CI-HMVC Modular extensions – – to comply to our “Domain Driven Design” architecture approach and it works well.


      1. Not a composer native framework  yet.
      2. HMVC Modularisation is what we want but its not the native structure of CI – there are some issues e.g. validation.
      3. ReST URIs are tied to controller structure.

1.2 The second option is CodeIgniter_Scaffold_REST was a quick POC hack of iScaffold to prove how useful it would be to get a ReST API along with the UI CRUD that iScaffold generates –


      1. none – it only served to motivate the developer of iScaffold to add a ReST API generation feature to iScaffold.


      1. not maintained – POC
      2. ReST URIs are tied to controller structure.

1.3 The third option is iScaffold which Igor updated to include a ReST server scaffolding feature –


      1. iScaffold offers separate code generation for API and/or CRUD GUI. Process is quite manual. Not as smooth as CIBonfire (Which does not scaffold a ReST API).


      1. Not maintained
      2. We already use CodeIgniter and know how to configure it for MSSQL and MySQL implementations. CIBonfire has its own DB libs which do not support MSSQL.
      3. ReST URIs are tied to controller and module structure.

1.4 CIBonfire – with Phil Sturgeon’s ReST server –


      1. We found that AngularJS could POST to this ReST Server even tough Apache cannot populate the $POST with an Angular $ payload.
      2. It has a API Key feature to secure access to the endpoint.
      3. Bonfire has Code Generation through a GUI.
      4. Bonfire has HMVC Modular extensions – to comply to our Domain Driven Design Architecture approach and it works well.
      5. Bonfire has USER, ROLES and ACTIONS Management bake in.
      6. Bonfire offers CRUD for Data Management through its full stack code generation.


      1. The ReST integration will be custom – not maintained by the CIBonfire team.
      2. Slow pace of progress on the CI Bonfire project.
      3. We already use CodeIgniter and know how to configure it for MSSQL and MySQL implementations. CIBonfire has its own DB libs which do not support MSSQL.
      4. No native code Generation for CRUD functionality.
      5. ReST URIs are tied to controller and module structure.

5. Apigility

0. apigility — -> finally someone understands the self hosted API requirement.!topic/apigility-users/PiDMTbaf9iA

Zend Framework uses the (SL) Service Locator Pattern and Symfony the (DI) Dependency Injection  and Inversion of Control Pattern:

For line of business applications DI is prefered over SL as SL hides the dependencies, which in turn makes it harder to maintain the applications.

Symfony is a “request response” framework not a MVC framework like CodeIgniter and Zend.


6. repo at

Leave a Reply