All the buzz at ZendCon 2013 was Apigility. From the previous ZendCon where the message was “mobile first” came the realization that without an API to run the mobile first there was not a reason to go mobile first. So the community took a step back and said “API First”.
Apigility is an API Engine which speaks HAL. HAL is Hypertext Application Language. Such a huge word! How big is Hypertext? And to build an API language which speaks Hypertext? This will become the common dialect of APIs.
The first question ZendCon asked was, “Where’s the Doctrine integration?” Soliant stepped forward and said, “We’ll build that.” And we did.
Help came in from the community for ODM support. I hadn’t considered the need for ODM but it’s core Doctrine support so we built ORM and ODM together. Some pieces of code work for both and other code is specific to one or the other. The integration of both is handled well.
The project started off with administration bundled along with server code. Administration code allows new API’s to be created through Apigility’s API then server code handles the serving of the API resources created with the Admin. Development became confused with these libraries intermingled so a split was made between Admin and Server. Each repository now went forward independently but they were split from the same code base.
At Soliant we used the new library to create an API with three separate databases and a connection to Mongo through ODM. One of these APIs accepts a Doctrine JSON schema then, with it, creates the entity, the table it defines, and creates an API to serve the data for that table. This kind of functionality would have taken months of resources and wouldn’t be as good as what Apigility enabled us to accomplish.
This project was not built with Test Driven Development. At the beginning of the project we could see no end solution as it was too far away. So unit tests were not added until the project was functionally complete. There arose a problem of the Admin requiring the Server and the Server requiring the Admin for testing that Travis could not compose, so the two libraries were merged. Thanks to their common ancestor git was able to merge them with little hassle.
The project has now been moved from Soliant Consulting to ZF Campus: Download it here. This was the plan all along and it’s satisfying to have made the hand-off.
Can’t see UI for admin.
So, I’m trying to get my head around Apigility. I already have a module that users DoctrineModule to interact with the DB. I created a new module called “Api”, and created my first REST service. I would like to pulish the data my first module already interacts with, in the REST service. I saw that Apigility generates a /module/Api/V1/Rest/MyService/MyServiceResource.php with the fetchAll() and fetch($id) methods.
I understand THAT’S what I need to replace to send my Doctrine entities, but all thest I’ve done have failed. I started trying a simple
public function fetch($id)
{
return [‘foo’ => ‘bar’];
}
That simple exampel worked for the RPC service, but not for the REST services.
What am I doing wrong? What should the fetch($id) method return?
Thanks. I’m a bit desperate.