Why is there a new generation of phpMAE?
There were some developments in the PHP world as well, with one affecting phpMAE primarily: Silex, the Symfony-based microframework that we built phpMAE upon, was deprecated by its creator. While that decision to focus Symfony’s efforts on a single framework probably made sense for them, it forced me to rethink how to develop phpMAE going forward. At the same time, the PHP Framework Interop Group has worked on and released quite some standards through which PHP development has evolved.
With significant projects that relied on the existing phpMAE version either nearing their end of life or in need of refactoring anyway, the decision was to refactor phpMAE as well to remove its dependency on Silex and rethink the approach to the Micro API engine.
The new phpMAE uses Slim instead of Silex. “Wait”, you may say, “so you replaced a third-party dependency with another?” Well, apart from the fact that I assume that Slim’s creator is less likely to shut down the framework, phpMAE also underwent a redesign that relies on standard PHP features and PHP-FIG standards and limits third-party dependencies for the majority of use cases. Therefore, as long as we keep the current design, we could drop Slim for something else, and most of it wouldn’t change at all. The majority of code that you write for execution by the 1.0.0-engine doesn’t even include references to phpMAE and can, therefore, be used outside of the engine in other PHP projects, too.
In phpMAE, you create classes. The controller concept from the previous version no longer exists. Every class is a single-file standard PHP class registered as an object of the phpmae:Class type in CloudObjects. All its public methods are automatically available through an HTTP interface. We currently support JSON-RPC 2.0 as the serialization protocol but are planning to add other interfaces, too. At the same time, it’s also possible to add the class as a dependency of another phpMAE class and call its methods locally within the same process. Classes can implement interfaces specified as phpmae:Interface and herewith provide a specific implementation of a generically defined API.
There’s also one particular type, phpmae:HTTPInvokableClass, that builts upon on PHP’s invokable classes - classes with an
__invoke() method that you can use as callables in PHP. A running phpMAE instance accepts any HTTP POST request for these classes without the need for an RPC serialization protocol, making them an ideal choice for simple webhook-style implementations.
So, what about resource-CRUD-style (“RESTful”) APIs? It’s no longer possible to define routes directly in a phpMAE class. Still, there’s a new way to build APIs with multiple endpoint URLs. You can create a phpmae:Router object that maps paths to different phpMAE classes. Routers even support some actions, such as performing redirects, directly as part of the RDF configuration.
That was probably a lot of information for a first look at the new version of phpMAE. We will continuously release extensive documentation for all features, as well as tutorials and guides on this blog!