On the Zend Framework blog there's a new tutorial posted showing you how you can get Laravel Homestead and Zend Framework playing nicely together. Fortunately it's relatively easy to get set up with these two technologies, it "just works".

Laravel Homestead is an interesting project by the Laravel community that provides a Vagrant box for PHP developers. It includes a full set of services for PHP developers, such as the Nginx web server, PHP 7.1, MySQL, Postgres, Redis, Memcached, Node, and more.

One the most interesting features of this project is the ability to enable it per project. This means you can run a vagrant box for your specific PHP project. In this post, we'll examine using it for Zend Framework MVC, Expressive, and Apigility projects. In each case, installation and usage is exactly the same.

They walk you through the download of the Homestead Vagrant box and the vagrant-hostsupdater package to help with renaming the application's local hostname. An example Homestead configuration is included as well as information on how to test and ensure your setup is working as expected.

Matthew Weier O'Phinney has a new post to his site showing you how to can use Composer to autoload Zend Framework modules right along with the rest of the ZF components.

One aspect of Zend Framework 3, we paid particular focus on was leveraging the Composer ecosystem. We now provide a number of Composer plugins for handling things such as initial project installation, registering installed modules with the application, and more. It's the "more" I particularly want to talk about.

With ZF2, we were able to realize the ability to install third-party modules into existing applications, enabling a module ecosystem. [...] For the v3 release, we wanted to solve this if we could. We were able to do so via a Composer plugin, zend-component-installer.

This allows ZF module authors to add details into the "extra" section of their Composer configuration, making it so the plugin understands how to load the module automatically. They've also created a package to help do the same for Apigility applications and lets you remove any calls to "getAutoloaderConfig" in your modules.

In an article posted to his site Rob Allen shows you how to hook in the OAuth2 authentication for an Apigility-based application with a pre-existing database table structure that may not match the defaults Apigility is looking for.

I have a client that's writing an Apigility API that needs to talk to a database that's already in place. This also includes the users table that is to be used with Apigility's OAuth2 authentication. Getting Apigility's OAuth2 integration to talk to a specific table name is quite easy. [...] However, if you want to use different column names, that's a bit trickier as they are hardcoded in the OAuth2StoragePdo class. To get Apigility's OAuth2 components to look at the correct columns, you create your own OAuth2 Adapter. I chose to extend ZFOAuth2AdapterPdoAdapter which extends OAuth2StoragePdo and go from there.

He includes the code for this extension of the PdoAdapter (a "OAuth2Adapter" class) in the post showing the definitions of the get user, set user and check password methods the OAuth2 flow needs to match users to OAuth sessions. He also includes the code for the "OAuth2AdapterFactory" class that's used to pull the custom PDO adapter class into Apigility and, along with some configuration changes, make it available for use. Then it's just a simple matter of changing the authentication type in the Apigility UI.

On the SitePoint PHP blog they've posted a new tutorial from Daniel Berman about using Zend Studio to create mobile applications in the same interface you're using (if you're a Zend Studio user) to create your PHP applications.

The world has turned mobile. This is not new, and it should therefore be no surprise to anyone that the results of the 2015 DevPulse survey by Zend show that a vast majority of PHP developers are working on, or intend to work on, mobile apps.

Mobile app development poses many challenges for developers, one of which is tying in the front end of the mobile application with the back-end web service APIs. This tutorial describes how to simultaneously create, test and modify both the front and back end of a modern mobile app using Zend Studio’s mobile development features.

He breaks the rest of the post up into several steps to help you get a simple mobile project up and running, complete with a basic Apigility API backend:

• Creating a Cloud Connected Mobile Project
• Previewing your App
• Developing the Back-End APIs
• Developing the Front-End
• Testing as an Android Native App
• Exporting a Native Application Package

The end result is a simple "cloud connected" application that can be installed directly on an Android device as a ".apk" package.

Michelango van Dam has a new post on his site today walking you through the process of running Apigility on Windows Azure. Apigility is a project from Zend that makes creating and maintaining APIs much simpler (based on the Zend Framework).

Since a couple of years I've been a fan of Microsoft Azure, the cloud platform by Microsoft. It offers a platform as a service (PaaS) in the form of Azure Websites which makes it a great solution to prototype and to play with new stuff. Last year Matthew Weier O'Phinney announced Apigility at ZendCon, a manager for API design. It was immediately clear that it would revolutionise the way we would design and manage REST API's.

Michelangelo walks you through the entire process, starting locally. He shows you how to clone and set up the latest version of Apigility and create a basic endpoint named "demo". He adds in a bit of code to handle the API request (returning user data) and includes an example of what the REST request looks like. With that up and running, he moves on to the Azure side of things. He shows you how to create a "web.config" file to configure the Azure server and run Composer as the install is being processed. He helps you get an Azure account set up and shows how to set up the website instance where you'll deploy the application, pointing it to a GitHub repository as a deploy source.

Matthew Weier O'Phinney has a new post sharing some of the details about using RPC and HAL in the Apigility API tool from Zend. HAL stands for "Hypermedia Access Language" and basically provides a way to define objects in an API and what they relate to.

A few days ago, we released our first beta of Apigility. We've started our documentation effort now, and one question has arisen a few times that I want to address: How can you use Hypermedia Application Language (HAL) in RPC services? Hypermedia Application Language is an IETF proposal for how to represent resources and their relations within APIs. Technically, it provides two mediatypes, application/hal+json and application/hal+xml; however, Apigility only provides the JSON variant.

He introduces some of the basics of HAL and includes an example of JSON output showing metadata about the current object such as a full link to the resource. He also includes an example of the "embedded" data, additional related data, other objects, with their own structure and links. He also briefly mentions what RPC is and how it works before getting into how to set up the endpoints in your Apigility API with the help of "ContentNegotiation" functionality.

Those interested in the Apigility project from Zend might want to check out this new post from Ralph Schindler on how it handles authentication and authorization for all of the requests.

Apigility takes a lightweight, layered, yet extensible approach to solving both problems of authentication and authorization. The infrastructure is already in place and ready to be configured to use, or for more advanced use cases: to be extended. Many of these feature can be easily explored through the Apigility user interface.

He gets into authentication first, defining it briefly before getting into the Apigility-specific implementation. He talks about the three methods (HTTP basic, HTTP digest and OAuth2) and mentions where it falls in the execution as well as some screenshots of its setup. Following this he talks about the other half of the equation, authorization. He covers the "Authentication" header, the identity types and where you can find the configuration settings. He finishes off the post with an in-depth look at the different components, events and services/models that make up the authentication and authorization system and make it work.

Zend has officially announced the release of the 1.0.0beta1 of Apigility, their API creation platform making it simpler for developers to get started making APIs, even around existing code.

We are pleased to announce the immediate availability of Apigility 1.0.0beta1! [...] This is our first beta release of Apigility, marking its initial API stability, and providing a solid preview of what to expect for the first stable release. [...] Apigility provides tools for describing and documenting your APIs, both RESTful and RPC. You can indicate the URL that provides a service, what HTTP methods are allowed, what representations (e.g., JSON, HTML, XML) can be provided, how many items to present per page of a collection, and more.

The release goes on to talk about some of the other features of Apigility including the standard of JSON responses, custom validation for incoming data and an implementation of the Swagger UI bundled for documentation of your service. There's also a list of things (with code examples on some) about what's changed in this beta release since 0.9.1. There's also a brief look at the end of the roadmap ahead, with an emphasis on a full, stable release soon.

Michelangelo van Dam has a new post sharing a method he's come up with for boostrapping Zend Framework v1 components inside of an Apigility-based application.

Apigility is a Zend Framework 2 tool that provides a REST API management interface, which is very useful if you want to build an API. Apigility can directly connect with your database and offer a full REST API for your application, but in most cases you already have an application build with Zend Framework 1.x (ZF1). Let's assume you have incorporated a lot of business logic in this application so it would be a waste not to use it building a rich REST API.

He uses the gitmodules functionality to bring his entire ZF1 application into the Apigility app's structure (or, alternatively, Subversion). He shows how to use Composer to install the actual Zend Framework v1 copy and how to pull in other third-party libraries. He includes the code you'll need to use to create a "ZF2APP_PATH" constant to get to the application path of Zend Framework v2 instance. He then gets into the main part - the actual autoloading and bootstrapping of the ZF1 classes/services. He gives a brief introduction to working with Apigility to make a new service and shows the update to the resource class.