PHP micro framework for your REST API – Part 1: Selection

With the large number of frameworks that exists today, picking the right one for your next project can feel overwhelming. To make things easier for you when choosing your PHP micro framework, I want to take an in-depth at the available micro frameworks that you can build your next REST API with. I’ll try to make a fair and unbiased review of them based on their pros and cons. I’ll not be discussing on how you should build your API, I leave that to Phil Sturgeon and I can’t recommend his excellent book, Build APIs You Won’t Hate, enough.

I’ve seen a few of these comparisons around on the interwebs, but find them very contradictory. They are usuallyally named something click-batey like “10 best and most amazing X for 2016 that will make you shit bricks!”. Then 7–8 of them are denounced as utter garbage and that you shouldn’t use them. This isn’t the approach I want to take here. I want to show my selection process before I get to the actual comparison. This is how I would approach it if I had to make a decision.

For comparison of these frameworks I often see a big focus on the performance metric. I’m not going to argue it’s a bad metric, but to me there are more important factors since most of the micro frameworks will be fast to a certain degree. So I’m going to ignore that metric in my comparison and take the ignorant “it probably is fast enough”-approach, ignorance is truly bliss sometimes. And I also don’t think that “we chose this framework because it can handle a gazillion of requests per second” is a good argument except in some very edgy edge cases. A great PHP micro framework delivers a lot more than performance in my opinion.

This is the first part of this series where I’ll gather all possible candidates I can find and run them through the list of what I consider important. Some will fall off, some will stay on, and in the end I can give my judgment on the ones that lasted until the bitter end. I have found 26 different micro frameworks. Here is a list of all of them in no order what so ever. Wave, Zaphpa, Bullet PHP, One PHP, Tonic, Silex, Slim, Phalcon, Limonade, Lumen, Fat-Free Framework, Flight, Jolt, Aura, Epiphany, FRAPI, Zend Expressive, Respect/Rest, Swiftlet, PolyFrameWork, Nanite, MicroMVC, Hackwork, Fitzgerald, Deano, Afro. Phew, that’s a lot.

Community & activity

The community around a framework is often what makes it or breaks it. A PHP micro framework isn’t depending on that to the same extent since it’s smaller by design. A large community around it is nice to have, but not a must. It brings maintenance, engagement, tools, packages and plugins to the table.

Community or not, the code needs to be maintained with regular activity. A framework without commits in the last three months or so I’ll consider dead and not even consider. Unless you’re willing to take over the maintenance of a framework or fork it, I don’t think it’s good to use a PHP micro framework that isn’t being maintained.


There need to be some sort of requirement for our candidates. Since I’m looking for a PHP micro framework to build a REST API with we need a few things fulfilled, or at least have the possibility of fulfilling those requirements. Also I need to clarify that I’m looking for frameworks, not components or packages. I want it to come as a package deal, it can be very minimal with the addition of extending it, that is enough for me.

First and foremost I’ll be looking at documentation. To me a framework isn’t a framework without excellent documentation. It boils down to developer experience, PHP Round Table have a great podcast episode on how these tie together. I’d never consider choosing a framework without extensive documentation, no matter what type of application I’m building. I might be harsh, but I don’t find a Github wiki page or readme sufficient as documentation when it comes to frameworks. For a package or a component I can live with that, but for a framework I expect more of the author and contributors.

What I want a PHP micro framework to provide for us is:

  • PSR-compatible autoloading. Since it’s 2016 now.
  • Not try to be a know-it-all. We want it to embrace the mentality of a framework. That is gluing together the best pieces available out there and presenting it in a nice fashion to the developer. If a framework is a “one file”-framework without dependencies, we shouldn’t bother. It’s then solving problems that have been solved somewhere else.
  • Routing. A rather obvious one, but it should be able to route on HTTP verbs (GET, POST, PUT, PATCH, DELETE). Another nice feature would be if we can group routes for API versioning.
  • Middleware. In supporting middleware we unlock some great potential for an API, such as global token authentication, rate limiting, etc.
  • Configuration. We want configuration with environment support.
  • Database. We need to store and retrieve data, since 99% of all PHP applications use either MySQL or PostgreSQL as their main persistent storage.
  • Cache. I do believe that cache is important, even though it’s not a deal breaker. But since I previously stated that I don’t care for performance as a metric, this is a good counter measure to that.
  • Logging. We all need to debug our applications at some point.
  • Testing. We should write tests for our applications to some extent.
  • Validation. An API often handles input from the consumer and that data needs to be validated.
  • Service container & providers. If we don’t have these, we’ll have a hard time extending the framework. Service providers can be seen as optional since we can probably do our bindings in the service container somehow.

A few features often ship with frameworks that I’d like not to see. I want to have the ability of removing them, since they have no place in a REST API. These are:

  • Views & templates. We don’t need to present HTML to our consumers, we should present JSON.
  • Sessions. We’ll be using a token based authentication for the API and therefor don’t need session handling.

Elimination round

Now that we’ve established some ground rules, it’s time to start wielding the hammer of doom to narrow down the list. I don’t think many frameworks claiming to be a PHP micro framework will survive this round. Eliminating the prospects that don’t deliver according to the list of requirements. In no particular order here are the ones that’s eliminated and why.

  • Zaphpa. Have no dependencies, can’t be trusted in my book.
  • Bullet PHP. No activity for almost 11 months, dead.
  • Wave. Extensive documentation filled with examples that made it look promising. It also had the features I was looking for. But then the last commit was around one year ago, dead.
  • One PHP. Wouldn’t qualify as a framework to me. Over six months ago since the latest commit, dead.
  • Limonade. It got me intrigued with good (even though a messy single page one) documentation, then I found that it’s a “one file”-framework trying to solve everything itself without any dependencies. That file that had no commits for over 2 years, dead.
  • Tonic. Some good ideas here, with HATEOAS support out of the box for example. But the documentation is limited to a one page readme file on github. No activity in the main branch for over six months, dead.
  • FRAPI. Interesting approach to building REST APIs. But the documentation is messy and there hasn’t been any commits to the master branch for almost two years, dead.
  • Nanite. Not really a framework, and only support GET and POST requests.
  • Fat-Free Framework. With an excellent site and documentation, it showed some real promise. But when looking at the code it has no dependencies and tried to solve everything on its own. No thank you.
  • Jolt. No activity for over a year, dead.
  • Epiphany. Trying to be a jack of all trades, not relying on any dependencies. No activity for over a year on top of that, dead.
  • Respect/Rest. Just a component, and it does not want to be a framework. So that’s a no-go.
  • Swiftlet. Another framework that doesn’t feel the need to depend on any other packages.
  • PolyFrameWork. Uhm, no habla espanol..?
  • MicroMVC. No commits to the actual source code for over 3 years, super dead.
  • hackwork. Not even a composer file.
  • Fitzgerald. No composer file either, over 3 years since last activity, dead.
  • Deano. Activity stopped over a year ago, dead.
  • Afro. No composer file, no activity, dead.
  • Flight. I was excited about this one. Seemed like it had a great philosophy as a micro PHP framework, extendable and flexible. Then I saw that it had no dependencies, and I don’t see a reason to reinvent the wheel.
  • Aura. Branded as packages that can be built into frameworks. The packages are of excellent quality but gluing them together to a framework is too much of a task for this post, and that’s why it fell out.
  • Phalcon. This stands out as it’s a framework written in C that’s available as a PHP extension. However that leaves no room for slimming it down. You either get it all or nothing.

The amount of dead frameworks is simply astounding. Frameworks should come with a “don’t try this at home kids” warning label on them. It seems many people are interested in the thought of creating a framework, but may not be as keen on maintaining it. A PHP micro framework need just as much tender loving care as the rest of the frameworks.

The survivors

It made me kind of sad that so many prospects got discarded in the elimination process, as I was hoping for more than one new and upcoming to be on the list. Perhaps there isn’t room enough for one more PHP micro framework, sounds a bit unlikely though. We are left with a list that could be named The Big Three and the newcomer.

  • Lumen
  • Silex
  • Slim
  • Zend Expressive

The perk of a short list is that it allows for an more in-depth review and comparison. It makes us go deeper in finding the “best” PHP micro framework. Lets begin with a short introduction of them before I dive into implementation in the next part of the series.

Lumen, by Laravel

PHP micro framework: Lumen, by Laravel

A new player in the world of micro frameworks. It’s a trimmed down version of Laravel, one of the worlds most popular PHP frameworks. This comes with many advantages for a PHP micro framework. The community around it is huge, and almost all concepts applicable to Laravel will be applicable to Lumen. Because of this, any community resource will be relevant. Also since it’s based on components from the Illuminate package that powers Laravel, any updates there goes into Lumen as well. This also ensures great maintenance and updates to the underlying packages, which are built on top of the Symfony packages. The synergies could not be better here.

It features a few things out-of-the-box, packages that derive from Laravel. Database, cache, encryption, events, queues and so forth. All we need to get the show on the road. In a best case scenario we can remove packages we don’t have a need for. Unfortunately we can’t always plug-and-play third party packages for Laravel since they might depend on extended functionality, but often we can adapt them or find an alternative that is specific to Lumen.

Community resources

For the most part these are for Laravel, but they’re also applicable to Lumen.

The Silex framework

The Silex Framework

A relative newcomer but has been around a little while longer than Lumen. You could say that this is a trimmed down version of Symfony, but I’d argue it’s slightly different. The Silex framework is created by Fabien Potencier, the creator of Symfony, so you can expect it to be built mostly with Symfony components. And it is. It’s also inspired by the Sinatra framework, a micro framework for Ruby. Since it’s based on Symfony components you never have to worry about the quality of code, or maintenance to stop. Symfony is the most popular PHP framework and the community around it is so extensive it’s hardly worth mentioning. You can find anything for this PHP micro framework.

It arrives with a few services that meets the requirements, such as logging, database and validation to name a few. I hope we can trim the features down to the bare essentials we want, since it comes with a template engine and a session handler for example. There’s also no shortage of third party packages available for it.

Community resources

Since Silex ties into Symfony so much, pretty much all of these resources are for Symfony.

Slim PHP framework

The Slim PHP framework

Let me repeat the date of the first stable release, November 2, 2010. It has actually been around in a stable version for over 5 years now! That’s an impressive track record for being one of the top contenders in the PHP micro framework battle today. I’m quite sure it has gone through a major evolution process during those years, but I’m very impressed by the team for keeping the Slim PHP framework up to date for all these years.

This is very bare-bone, all you get supplied with is an application container, routing and an interface for HTTP requests and responses, including middleware. This is very promising since we can extend it in any way we please. There are also many, many packages with implementations for it. If you want a true micro PHP framework, this might be your choice.

Community resources

The community around it is substantially smaller than the other two big frameworks, mainly because it doesn’t have an older parent. However implementations aren’t as specific as in the other frameworks where you have many packages with APIs tied to them.

Zend Expressive

Zend Expressive

The new kid on the block as a PHP micro framework that was announced in August 2015. It does not have a stable release yet, there is only a release candidate as I’m writing this. With that said you should be extremely cautious to use this in production, and there might be some breaking changes before a stable version is ready. But it shows great promise and has a very modern framework approach. It’s fully PSR–7 compatible and is based on middleware. I probably don’t have to tell you about Zend, the giant in the PHP community with its Zend Framework that have been around for ages. This is completely different from the Zend Framework though but you can expect quality because of it.

It comes with a minimal core, and you can then choose what components you want to include. It supports a few different routers and dependency injectors, and there’s an option to include a template engine, but that isn’t something we’re interested in. All in all we get a minimal framework with excellent flexibility and ability to extend it.

Community resources

Since it’s so new and it differs so much from Zend Framework there isn’t much community around the framework at the moment. The framework provides best practices more than a toolbox of solving certain tasks, that’s why I don’t consider the lack of community alarming since we have the entire PHP community at our disposal.

Summing up our quest for a PHP micro framework

We’ve taken a look at many candidates for being a good PHP micro framework we could build a REST API with. However it turned out that only a few, four to be specific, made the cut. We’ve briefly looked at the different frameworks in terms of background, features, current activity as well as the community around them. All of them seem like good options at the moment. Lumen and Silex provide a larger toolbox while Slim and Zend Expressive are more DIY solutions. All features lacking in Slim and Zend Expressive can be implemented using packages that you tie into your application, this could even be packages from the other frameworks.

It comes down to personal preference what you want as your PHP micro framework. Do you want full flexibility? Even though you’ll have to do some coding to get features that are provided for you otherwise. Do you want a complete toolbox from the start? If you find sacrificing a bit of flexibility, and maybe performance, to be worth it.

Whichever you go with, I think they’re all great options as a PHP micro framework. In the next part I’ll code a basic API in all of the three and report on the developer experience for each of them. Hopefully I’ve shed some light on the current frameworks and why they are, or are not, suitable as micro frameworks for a REST API.

  • Thanks, interesting article! I would like to add that this:

    1. There are MUCH more frameworks in the PHP world, some of them have 10-50x (!) more stars on GitHub than the ones mentioned. It’s insane how large the PHP world has become.

    2. Also – just my personal opinion – small commit activity doesn’t mean something bad, maybe the project has just reached a very stable and very final state, which is totally okay for something that wants to be as micro as possible.

    3. I’ve seen micro frameworks mainly used by agencies and people who are not focussed on pure PHP development, so having no composer.json might not be a bad thing at all. We are looking at these things from a senior/expert perspective, but 100.000s of people just need a basic application skeleton and have no idea about MVC, don’t even know what a dependency is and just want to make some simple database calls. The amount of people who just need low-end sites is enourmous, and these people don’t need REST, ORM etc.. We should care about these people and have them in mind when analyzing software.

    • Thanks! I chose to focus on micro frameworks only, and I guess I had to make a subjective decision of what I considered a micro framework to be. The frameworks with 10-50x more stars probably didn’t make the cut because they were “too big”. Got any suggestions on frameworks I missed? I would not mind revising the post with new frameworks if there are some I’ve missed.

      I think that small commit activity and not having a `composer.json` file ties into each other. It means that no effort is made for keeping the framework, and in the end the applications that rely on it, up to date with bug and security fixes. And yes, people need simple frameworks for building small applications. I decided to focus this one for more experienced developers looking for a framework to build a REST API with. But Silex is a great example where you can build a minimal application with some database calls and some Twig templates. Using Composer for those small applications is for me not a stretch of what we can demand even of a junior developer 🙂

  • Viva

    Very interesting article, thank so much it helped me a lot

  • Zsolt

    You should also try equip framework and radar. Both are really tiny things, based ADR (Action-Domain-Responder pattern) and psr-7.

    • Niklas Modess

      They both look really promising, I like the approach ADR takes. I will dive deeper, test them out and possibly update the post!

  • Nice research!

    I would advise though anyone to use RESTLER ( ) – it is built “exclusively” for building apis with versioning, authentication, throttling etc. The best thing is that it automatically generates a resources.json for swagger/open apis with all routes, methods, docs, parameters etc., parses your php doc blocks and have functional explorer like

    Amazing tool, highly recommended 🙂

    • Niklas Modess

      I’m not sure if I’m stupid or not, but I can’t seem to find the documentation for it 🙂

  • I will be waiting for part 2 :).

    • kennii

      excellent work btw.

  • Great post thanks. It was really helpfull to me as it’s the firts time I will work with a php micro framework and it was difficult to me to choose one
    I am really looking forward to reading part 2

  • Great article. I am looking forward part 2 🙂
    Did you hear of ?

    • Niklas Modess

      Thank you. I’ll take a closer look at it!

  • Pingback: RESTFUL API 작성 – Logging();()

  • Azaz Qadir

    Slim is great for creating Rest API and it’s lightweight and easy to learn. Here is an example of how easy it is to create Rest API using Slim:

  • Cool article! Thank you very much! I tried to find a framework myself but hardly found a half of those you listed.
    If I may make one critical remark, for me, no activity for one year on github is not an indicator, that the framework is abandoned. For example Limonade seems to be a productive framework which has a developer and dozens of websites in the back ground. For me a no-go indicator is when you go to the website listed as built on that framework, but you find out, the website changed the framework.

    • Niklas Modess


      But I do not agree with you on this point. Limonade first and foremost is a “try to solve it all by itself”-framework without any external dependencies. That to me is a valid point for not going further with the framework in this post. Secondly, if the framework had external dependencies but were not updated in a year, how would you know that security and performance patches were implemented? Sure a framework can have a solid foundation and be production worthy, but it’s kind of a smell to me when it hasn’t been updated in over a year.

  • Maksym Minenko

    A very nice research indeed! Thanks a lot.

  • Pingback: php restful api framework comparison - دسرا()

  • Leonardo Cabral

    Interesting article. Albeit the lack of better requirements for research methodology related with the framework performance and scalability (a simple 1000 “Hello world” on Apachebench will give enough request data to make a more feasible elimination round.) Flight – a disqualified one – for example will make 1000 requests before 500ms. And here’s two of your survivors: Lumen (5.2) takes 2500ms and Slim (3.4) takes 4500ms to do the same task. I don’t know you but as a enterprise/startup player it counts a lot.

    I understand your preference for dependencies but nowadays with Composer the microframework paradigm is to build a lean enviroment, with the best of many worlds.

    In general Its a good article. I’m ok with that.

    Happy 2017!

    • Performance is often something that shouldn’t be considered when choosing a framework. All micro frameworks are fast to a certain extent, and with PHP7 it’s even a smaller factor because of the large performance improvements that the language brings to the table. I also wrote in the article that I would not take performance into consideration for eliminating frameworks. If extreme performance is a requirement, people will probably do their own extensive research into that aspect. I hope. 🙂

      Happy 2017 to you too!