Building web APIs is becoming an increasingly common method of reusing business logic across client platforms. The Zend Framework team has created an API builder called Apigility to help us construct our APIs. Version 1.0 has been a wonderful starting point for those of us trying to automate the tasks of creating controllers, routing configuration, filtering and validating input, etc.
Yesterday (4/16/15) the Apigility team released version 1.1, which includes a few very useful new features and enhancements. These include performance improvement for the administration UI (via a complete rewrite), the ability to create deployment packages, and per-API authentication. You can see the full change log here.
For CRUD-based systems there is now a Database Autodiscovery feature that allows you to specify which tables in your database you’d like to expose via web services and automatically adds basic validation based on the table’s column types. I’ll be interested to see how this works with IBM DB2.
If you’d like help getting started using Apigility to build web APIs check out the Apigility resources in The Learning Hall.
My company is creating an API using ZF2 on Zend Server via the PHP Toolkit. We are keeping our backend logic on RPG and the API allows us to call it via our new interface. One of the biggest questions of development when you start separating out your pieces is where and how you should be validating your data and which piece has what responsibility.
As a general guideline you want to have your parameter validation done in your view or PHP and your logic validation done in RPG. Let me expand/explain:
Parameter Validation: This is validating the type of data you will be using to call the API. The checks you will run are, for example, if the field is alpha or numeric. If the field is numeric, does it have any decimals or allow negative numbers.
Logic Validation: Once the data has been validated that is the right format and type of data, your API will validate if the call is correct. For example if you are wanting to delete a product the parameter validation will make sure the product ID that was submitted was in the correct format and then the API will determine if the product actually exists or is even allowed to be deleted (aka logic).
By having this plan in place when developing or expanding your project your developers can know who carries what responsibility.
Zend recently released Zend Framework 2.4 and with it brought fixes, enhancements, and long term support! With Zend Server it makes it very easy to update the framework installed on your system and used by default (and revert back to earlier framework versions if needed) so I am always one to try the newest released versions.
Yes… I am one of those early adopters you always hear about. Though with Zend Server and how it manages the libraries for ZF2 it really is a ‘low risk’ situation and I want my company’s software product to be used and effective in the latest version when possible. So I took the plunge and updated like I had for the past 6 updated releases of ZF2 and it had gone over flawlessly. This time… I had a bug.
Whether in my ignorance or newb-ness I attributed this to some time of backward compatibility break or change of functionality. Also, considering that IBM i and DB2 are a little different (a good different mind you) on the back end I wondered if some of the support for our beloved machine had been broken. I contacted a guru in the ZF2 world named Samsonasik. He is a fantastic coder and has helped me MANY times. I had him look at my code, the things I was doing, and see that my code worked fine in ZF 2.3.7 but broke in ZF 2.4. At the end of our session he suggested I post an issue to the GitHub repository for ZF2 and he would comment on it.
In this moment, dear reader, understand I felt like I was really helping out our IBM i community! I had ventured forth, tried something new, and found an error that couldn’t be explained by my coding! I was making sure the IBM i community had a working Zend Framework with which they could develop their applications on. I dare say I was a little proud of myself.
I posted my Issue to GitHub and the feedback was pretty quick from the developers and community. Lots of people asked about my coding or caching of the server… all presented answers came back that I had found a legitimate bug. It wasn’t until the head of the ZF2 project got on and suggested I had caching on… but it was in some of the main core files. There.. sitting in public/index.php was a line from EDPSuperLiminal that caching was still on and the culprit. I commented out this line and my code worked fine. Issue closed.
I write all this to tell you, dear reader, that you need to find a way to turn off and clear your cache when you are upgrading your framework. Save yourself some heartache and troubles and setup a plan for this so you can have an easy upgrade path on your server. Hopefully my story saved you some stress and embarrassment!