Overview

Apigility Skeleton Application

Repository abandoned 2019-12-31

This repository has moved to laminas-api-tools/api-tools-skeleton.

Requirements

Please see the composer.json file.

Installation

Via release tarball

Grab the latest release via the Apigility website and/or the releases page; each release has distribution tarballs and zipballs available.

Untar it:

$ tar xzf zf-apigility-skeleton-{version}.tgz

(Where {version} is the version you downloaded.)

Or unzip, if you chose the zipball:

$ unzip zf-apigility-skeleton-{version}.zip

(Where {version} is the version you downloaded.)

Via Composer (create-project)

You can use the create-project command from Composer to create the project in one go (you need to install composer):

$ curl -s https://getcomposer.org/installer | php -- --filename=composer
$ composer create-project -sdev zfcampus/zf-apigility-skeleton path/to/install

Via Git (clone)

First, clone the repository:

# git clone https://github.com/zfcampus/zf-apigility-skeleton.git # optionally, specify the directory in which to clone
$ cd path/to/install

At this point, you need to use Composer to install dependencies. Assuming you already have Composer:

$ composer install

All methods

Once you have the basic installation, you need to put it in development mode:

$ cd path/to/install
$ composer development-enable

Now, fire it up! Do one of the following:

  • Create a vhost in your web server that points the DocumentRoot to the public/ directory of the project
  • Fire up the built-in web server in PHP(note: do not use this for production!)

In the latter case, do the following:

$ cd path/to/install
$ php -S 0.0.0.0:8080 -ddisplay_errors=0 -t public public/index.php
# OR use the composer alias:
$ composer serve

You can then visit the site at http://localhost:8080/ - which will bring up a welcome page and the ability to visit the dashboard in order to create and inspect your APIs.

NOTE ABOUT USING APACHE

Apache forbids the character sequences %2F and %5C in URI paths. However, the Apigility Admin API uses these characters for a number of service endpoints. As such, if you wish to use the Admin UI and/or Admin API with Apache, you will need to configure your Apache vhost/project to allow encoded slashes:

AllowEncodedSlashes On

This change will need to be made in your server's vhost file (it cannot be added to .htaccess).

NOTE ABOUT OPCACHE

Disable all opcode caches when running the admin!

The admin cannot and will not run correctly when an opcode cache, such as APC or OpCache, is enabled. Apigility does not use a database to store configuration; instead, it uses PHP configuration files. Opcode caches will cache these files on first load, leading to inconsistencies as you write to them, and will typically lead to a state where the admin API and code become unusable.

The admin is a development tool, and intended for use a development environment. As such, you should likely disable opcode caching, regardless.

When you are ready to deploy your API to production, however, you can disable development mode, thus disabling the admin interface, and safely run an opcode cache again. Doing so is recommended for production due to the tremendous performance benefits opcode caches provide.

NOTE ABOUT DISPLAY_ERRORS

The display_errors php.ini setting is useful in development to understand what warnings, notices, and error conditions are affecting your application. However, they cause problems for APIs: APIs are typically a specific serialization format, and error reporting is usually in either plain text, or, with extensions like XDebug, in HTML. This breaks the response payload, making it unusable by clients.

For this reason, we recommend disabling display_errors when using the Apigility admin interface. This can be done using the -ddisplay_errors=0 flag when using the built-in PHP web server, or you can set it in your virtual host or server definition. If you disable it, make sure you have reasonable error log settings in place. For the built-in PHP web server, errors will be reported in the console itself; otherwise, ensure you have an error log file specified in your configuration.

display_errors should never be enabled in production, regardless.

Vagrant

If you prefer to develop with Vagrant, there is a basic vagrant recipe included with this project.

This recipe assumes that you already have Vagrant installed. The virtual machine will try to use localhost:8080 by default, so if you already have a server on this port of your host machine, you need to shut down the conflicting server first, or if you know how, you can reconfigure the ports in Vagrantfile.

Assuming you have Vagrant installed and assuming you have no port conflicts, you can bring up the Vagrant machine with the standard up command:

$ vagrant up

When the machine comes up, you can ssh to it with the standard ssh forward agent:

$ vagrant ssh

The web root is inside the shared directory, which is at /var/www; this is also the home directory for the vagrant issue, which will be the initial directory you land in once you connect via SSH.

The image installs composer during provisioning, meaning you can use it to install and update dependencies:

# Install dependencies:
$ vagrant ssh -c 'composer install'
# Update dependencies:
$ vagrant ssh -c 'composer update'

You can also manipulate development mode:

$ vagrant ssh -c 'composer development-enable'
$ vagrant ssh -c 'composer development-disable'
$ vagrant ssh -c 'composer development-status'

Vagrant and VirtualBox

The vagrant image is based on bento/ubuntu-16.04. If you are using VirtualBox as a provider, you will need:

  • Vagrant 1.8.5 or later
  • VirtualBox 5.0.26 or later

For vagrant documentation, please refer to vagrantup.com

Docker

If you develop or deploy using Docker, we provide configuration for you.

Prepare your development environment using docker compose:

$ git clone https://github.com/zfcampus/zf-apigility-skeleton
$ cd zf-apigility-skeleton
$ docker-compose build
# Install dependencies via composer, if you haven't already:
$ docker-compose run apigility composer install
# Enable development mode:
$ docker-compose run apigility composer development-enable

Start the container:

$ docker-compose up

Access Apigility from http://localhost:8080/ or http://<boot2docker ip>:8080/ if on Windows or Mac.

You may also use the provided Dockerfile directly if desired.

Once installed, you can use the container to update dependencies:

$ docker-compose run apigility composer update

Or to manipulate development mode:

$ docker-compose run apigility composer development-enable
$ docker-compose run apigility composer development-disable
$ docker-compose run apigility composer development-status

QA Tools

The skeleton ships with minimal QA tooling by default, including zendframework/zend-test. We supply basic tests for the shipped Application\Controller\IndexController.

We also ship with configuration for phpcs. If you wish to add this QA tool, execute the following:

$ composer require --dev squizlabs/php_codesniffer

We provide aliases for each of these tools in the Composer configuration:

# Run CS checks:
$ composer cs-check
# Fix CS errors:
$ composer cs-fix
# Run PHPUnit tests:
$ composer test
Comments
  • Error when updating, installing module, and upgrading.

    Error when updating, installing module, and upgrading.

    I tried to use: composer install doctrine/doctrine-orm-module and I get an error:

    Your requirements could not be resolved to an installable set of packages.
    
      Problem 1
        - The requested package zfcampus/zf-apigility-admin-ui (locked at 1.2.2, required as ^1.2.3) is satisfiable by zfcampus/zf-apigility-admin-ui[1.2.2] but these conflict with your requirements or minimum-stability.
      Problem 2
        - Can only install one of: zendframework/zend-hydrator[1.1.0, 1.0.0].
        - Can only install one of: zendframework/zend-hydrator[1.1.0, 1.0.0].
        - Can only install one of: zendframework/zend-hydrator[1.1.0, 1.0.0].
        - doctrine/doctrine-orm-module 1.0.0 requires zendframework/zend-hydrator ^1.1 -> satisfiable by zendframework/zend-hydrator[1.1.0].
        - Installation request for doctrine/doctrine-orm-module ^1.0 -> satisfiable by doctrine/doctrine-orm-module[1.0.0].
        - Installation request for zendframework/zend-hydrator (locked at 1.0.0) -> satisfiable by zendframework/zend-hydrator[1.0.0].
    

    If I try to update: composer update, error again:

    Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException' with message
    'Module (AssetManager) could not be initialized.' in C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php:203 Stack trace: #0 C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php(175): Zend\ModuleManager\ModuleManager-
    >loadModuleByName(Object(Zend\ModuleManager\ModuleEvent)) #1 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php(97): 
    Zend\ModuleManager\ModuleManager->loadModule('AssetManager') #2 [internal function]: 
    Zend\ModuleManager\ModuleManager-
    >onLoadModules(Object(Zend\ModuleManager\ModuleEvent)) #3 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(490): 
    call_user_func(Array, Object(Zend\ModuleManager\ModuleEvent)) #4 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(251): Zend\EventMa in 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php on line 203
    

    If I try to solve the AssetManager removal with: vendor/bin/apigility-upgrade-to-1.5.bat, error again:

    Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException' with message
    'Module (ZF\DevelopmentMode) could not be initialized.' in C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php:203 Stack trace: #0 C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php(175): Zend\ModuleManager\ModuleManager-
    >loadModuleByName(Object(Zend\ModuleManager\ModuleEvent)) #1 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php(97): 
    Zend\ModuleManager\ModuleManager->loadModule('ZF\\DevelopmentM...') #2 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(271): 
    Zend\ModuleManager\ModuleManager-
    >onLoadModules(Object(Zend\ModuleManager\ModuleEvent)) #3 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(143): 
    Zend\EventManager\EventManager->triggerListeners(Object(Zend\ModuleManager\ModuleEven in 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php on line 203
    

    edit:

    I discovered what happened for the DevelopmentMode error. Before updating I used the zftool to create a module and it modified the application.config.php instead of the modules.config.php... After removing the application.config.php and renaming application.config.php.old to application.config.php I got new errors:

    Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException' with message
    'Module (Zend\Hydrator) could not be initialized.' in C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php:203 Stack trace: #0 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php(175): 
    Zend\ModuleManager\ModuleManager-
    >loadModuleByName(Object(Zend\ModuleManager\ModuleEvent)) #1 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php(97): 
    Zend\ModuleManager\ModuleManager->loadModule('Zend\\Hydrator') #2 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(271): 
    Zend\ModuleManager\ModuleManager-
    >onLoadModules(Object(Zend\ModuleManager\ModuleEvent)) #3 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(143): 
    Zend\EventManager\EventManager->triggerListeners(Object(Zend\ModuleManager\ModuleEvent)) #4 
    C:\ in C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php on line 203
    

    I'm kinda stuck, what can I do?

    PHP: 5.6.24

    opened by viyirenov 20
  • 500 Internal Server Error

    500 Internal Server Error

    I configured the VHOST and get the 500 Internal Server Error when I choose the Example provided by default. Below are the request and responses. Is this a known issue or I am doing something wrong?

    Thank you Sumit

    Request URL: http://zf2-apigility.localhost/admin/api/module/ZF.Apigility.Example/rest?version=1 Request Method: GET Status Code: 500 Internal Server Error

    Request Headers Accept: application/hal+json, application/json, /; q=0.01 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Connection: keep-alive Host: zf2-apigility.localhost Referer: http://zf2-apigility.localhost/admin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36 X-Requested-With: XMLHttpRequest Query String Parametersview sourceview URL encoded version: 1

    Response Headers Connection: close Content-Length: 222 Content-Type: application/api-problem+json Date: Thu, 10 Oct 2013 12:11:39 GMT Server: Apache/2.4.4 (Win64) PHP/5.4.12 X-Powered-By: PHP/5.4.12

    Response {"problemType":"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html","title":"Internal Server Error","httpStatus":500,"detail":"Unable to determine configuration path for module \u0022ZF\Apigility\Example\u0022"}

    opened by sumityadav 15
  • Prepare skeleton to use ZF v3 releases by default

    Prepare skeleton to use ZF v3 releases by default

    For the next minor release (1.4), we'll be using ZF v3 components by default. This patch does the followign:

    • Sets the minimum supported PHP version to 5.6.
    • Removes the zendframework/zendframework dependency entirely; zf-apigility and others bring in zend-mvc already, which gives us the MVC foundation necessary.
    • Adds zendframework/zend-component-installer as a requirement.
    • Adds zfcampus/zf-asset-manager as a development requirement.
    • Removes zendframework/zftool as a development requirement.
    • Updates all Apigility requirements, both production and development, to their latest stable versions.
    • Adds Composer scripts for:
      • enabling development mode (composer development-enable)
      • disabling development mode (composer development-disable)
      • reporting development mode status (composer development-status)

    This has been tested quite a bit along with the zf-apigility-admin 1.5.0 release, but likely needs more testers. In particular, I'm curious what the "install" experience is like, and whether or not people are getting endless requests to update their module configuration, or if it "just installs".

    enhancement 
    opened by weierophinney 11
  • fresh install, run  php public/index.php got PHP Fatal error:  No base path provided

    fresh install, run php public/index.php got PHP Fatal error: No base path provided

    Steps to reproduce:

    1. Download apigility 1.4.0 from https://apigility.org/download
    2. Create new API
    3. Run command from php public/index.php
    $ php public/index.php 
    PHP Fatal error:  Uncaught Zend\View\Exception\RuntimeException: No base path provided in /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Helper/BasePath.php:38
    Stack trace:
    #0 [internal function]: Zend\View\Helper\BasePath->__invoke('/img/favicon.pn...')
    #1 /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Renderer/PhpRenderer.php(394): call_user_func_array(Object(Zend\View\Helper\BasePath), Array)
    #2 /Users/samsonasik/www/apigility/module/Application/view/layout/layout.phtml(10): Zend\View\Renderer\PhpRenderer->__call('basePath', Array)
    #3 /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Renderer/PhpRenderer.php(502): include('/Users/samsonas...')
    #4 /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/View.php(207): Zend\View\Renderer\PhpRenderer->render()
    #5 /Users/samsonasik/www/apigility/vendor/zendframework/zend-mvc/src/View/Http/DefaultRenderingStrategy.php(105): Zend\View\View->render(Object(Zend\View\Model\ViewModel))
    #6 /Users/samsonasik/www/apigility/vendor/zend in /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Helper/BasePath.php on line 38
    
    Fatal error: Uncaught Zend\View\Exception\RuntimeException: No base path provided in /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Helper/BasePath.php on line 38
    
    Zend\View\Exception\RuntimeException: No base path provided in /Users/samsonasik/www/apigility/vendor/zendframework/zend-view/src/Helper/BasePath.php on line 38
    
    Call Stack:
        0.0009     358312   1. {main}() /Users/samsonasik/www/apigility/public/index.php:0
        2.9370    4623032   2. Zend\Mvc\Application->run() /Users/samsonasik/www/apigility/public/index.php:43
        2.9374    4625112   3. Zend\Mvc\Application->completeRequest() /Users/samsonasik/www/apigility/vendor/zendframework/zend-mvc/src/Application.php:326
        2.9374    4625112   4. Zend\EventManager\EventManager->triggerEvent() /Users/samsonasik/www/apigility/vendor/zendframework/zend-mvc/src/Application.php:369
        2.9374    4625112   5. Zend\EventManager\EventManager->triggerListeners() /Users/samsonasik/www/apigility/vendor/zendframework/zend-eventmanager/src/EventManager.php:143
        2.9382    4710656   6. Zend\Mvc\View\Http\DefaultRenderingStrategy->render() /Users/samsonasik/www/apigility/vendor/zendframework/zend-eventmanager/src/EventManager.php:271
        3.1214    4954008   7. Zend\EventManager\EventManager->triggerEvent() /Users/samsonasik/www/apigility/vendor/zendframework/zend-mvc/src/View/Http/DefaultRenderingStrategy.php:123
        3.1214    4954008   8. Zend\EventManager\EventManager->triggerListeners() /Users/samsonasik/www/apigility/vendor/zendframework/zend-eventmanager/src/EventManager.php:143
        3.1215    4955232   9. Zend\Mvc\View\Http\DefaultRenderingStrategy->render() /Users/samsonasik/www/apigility/vendor/zendframework/zend-eventmanager/src/EventManager.php:271
    
    opened by samsonasik 10
  • Hotfix/development mode (plus some vagrant documentation)

    Hotfix/development mode (plus some vagrant documentation)

    Since 'ZF\DevelopmentMode', obviously must be included in config/application.config.php so that it can be run before a config/development.config.php has been deployed, this means that the application will always expect the module to exist. If you compose a project with --no-dev, if composer does not install the module, the application throws a fatal error from the module manager:

    Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException' with message 'Module (ZF\DevelopmentMode) could not be initialized.' in /vagrant/vendor/zendframework/zendframework/library/Zend/ModuleManager/ModuleManager.php on line 195
    

    This PR also removes the composer.lock file, adds .vagrant to .gitignore and adds a helpful welcome message to the end of Vagrantfile.

    opened by jeremiahsmall 10
  • InputFilter not used for filtering `POST` data

    InputFilter not used for filtering `POST` data

    Hello,

    I have a question or an issue, but I am not sure which of the two it is since I don't know if the behavior is wrong or expected. Let me explain.

    When I register an inputFilter for a certain entity and patch an entity with data (a field) that is not registered in the inputFilter I get an ApiProblem response with status 400 and a message "Unrecognized field name".

    Now in another case I post data for creating a new entity and I include the same invalid field in the data. When I look at the $data object in the create method in my ResourceListener the $data is apparently not filtered by the inputFilter, because unknown data is still present in the $data object. Normally I would expect the inputFilter to take care of unknown/unwanted by filtering it. Something like this:

    $inputFilter->setData($unfilteredData);
    if(!$inputFilter->isValid()){
        ...throw exception or return ApiProblem
    }
    $filteredData = $inputFilter->getValues();
    

    Is the module (as the name would suggest) only for validation of data and that is why the registered inputFilters are not used for filtering POST data at all? Does it mean I still manually have to pull the data trough the filter in my ResourceListener. I also looked at the zfcampus/zf-content-validation src files but could not find anything related to actually filtering the data.

    Thanks.

    opened by Wilt 9
  • Version 1.3 requires PHP 5.5 but the Vagrant box has PHP 5.4.43

    Version 1.3 requires PHP 5.5 but the Vagrant box has PHP 5.4.43

    The Vagrant install does not install PHP 5.5 so you cannot compose your vendors from within the Vagrant box.

    vagrant@precise64:/vagrant$ ./composer.phar install
    Loading composer repositories with package information
    Installing dependencies (including require-dev) from lock file
    Your requirements could not be resolved to an installable set of packages.
    
      Problem 1
        - This package requires php >=5.5 but your PHP version (5.4.43-1+deb.sury.org~precise+1) does not satisfy that requirement.
    
    bug 
    opened by TomHAnderson 8
  • Getting

    Getting "Unable to fetch hydrators for hydrator dropdown...." error

    screen shot 2014-01-16 at 23 19 45

    I was setting up zf2 skeleton+apigility using Rob's tutorial, everything was fine, but i got such error.

    To reproduce:

    1. Create an API
    2. Click on REST services.

    php 5.5.8, opcache off, apache or built-in server - the same result.

    opened by permiakov 8
  • Vagrant + index.php cleanup

    Vagrant + index.php cleanup

    • Added Vagrantfile + .puppet/ directory which includes manifests from www.puphpet.com. The Vagrantfile should work by default with both virtualbox and vmware providers. Comes with PHP 5.4 + xdebug, apache, and mysql.
    • Added a quick check for vendor/autoload and throws a runtime exception if the file is missing rather than fatal error'ing.
    opened by spiffyjr 8
  • Error when composer update

    Error when composer update

    I tried to composer update and I got this error:

    Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException' with message
    'Module (AssetManager) could not be initialized.' in C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php:203 Stack trace: #0 C:\apigility\vendor\zendframework\zend-
    modulemanager\src\ModuleManager.php(175): Zend\ModuleManager\ModuleManager-
    >loadModuleByName(Object(Zend\ModuleManager\ModuleEvent)) #1 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php(97): 
    Zend\ModuleManager\ModuleManager->loadModule('AssetManager') #2 [internal function]: 
    Zend\ModuleManager\ModuleManager-
    >onLoadModules(Object(Zend\ModuleManager\ModuleEvent)) #3 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(490): 
    call_user_func(Array, Object(Zend\ModuleManager\ModuleEvent)) #4 
    C:\apigility\vendor\zendframework\zend-eventmanager\src\EventManager.php(251): Zend\EventMa in 
    C:\apigility\vendor\zendframework\zend-modulemanager\src\ModuleManager.php on line 203
    
    opened by viyirenov 6
  • Can't composer update!

    Can't composer update!

    Hey team,

    If you do a composer update on the skeleton, Apigility won't work anymore.

    The requirements for "zendframework/zendframework": "^2.5.3", are satisfiable by 2.7.6 which installs zendframework/zend-servicemanger:2.7.6. This version doesn't have the FactoryInterface in the right location. It seems to be rectified in 3.0, but I'm not sure if apigility is ready for that.

    When you composer install zfcampus/zf-api-problem on its own, it installs ZF3 which has fixed this issue. I guess you wouldn't pick it up if you're just running tests against that repo on its on.

    I'm happy to submit a pull request, but it'll be broken if the requirement changes to ZF3.

    Reason: I'm trying to keep apigility up to date, and the composer requirements are too flexible if there are compatbility issues. Either the skeleton needs to be locked to specific versions, or at least have less flexible requirement tags.

    Thanks guys!

    opened by aaronweatherall 6
  • Missing Zend-i18n package

    Missing Zend-i18n package

    Hello,

    I just installed a fresh install of Apigility with curl -sS https://apigility.org/install | php (according to documentation).

    I started playing with it (it's my first time using Apigility) but I couldn't add an alpha validator on my field. Looking at the console I realized I had the following error:

    PHP Fatal error:  Uncaught Error: Class 'Zend\I18n\Validator\Alpha' not found
    

    To fix the issue, I added the zendframework/zend-i18n package with composer require zendframework/zend-i18n and added 'Zend\\I18n' in modules.config.php (it was done by composer but there was a \ missing).

    I hope it helps :)

    opened by jbelien 3
  • composer install on Vagrant box fails

    composer install on Vagrant box fails

    I just did a new install and at the end it says to run: vagrant ssh -c 'composer install', so I did and got:

    Loading composer repositories with package information
    Installing dependencies (including require-dev) from lock file
    Nothing to install or update
    
                                                                                                            
      [ErrorException]                                                                                      
      file_put_contents(/var/www/vendor/composer/installed.json): failed to open stream: Permission denied  
                                                                                                            
    
    install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
    
    Connection to 127.0.0.1 closed.
    

    So I tried to vagrant ssh and run composer install and got the same result.

    So I sudo vagrant ssh and it works (with nothing to do), though with the composer warning to not run as root.

    It seems the ssh is using user vagrant but the /var/www is setup with www-data user and group so the vagrant user doesn't have permission.


    I'm not sure if it's related, but I just noticed this error in the vagrant up output:

    default: dpkg-preconfigure: unable to re-open stdin: No such file or directory

    opened by MECU 1
  • A 404 error occurred in Apigility when I go to /oauth/authorize

    A 404 error occurred in Apigility when I go to /oauth/authorize

    When I go to the following url:

    http://localhost/zf-apigility-skeleton/public/v1/oauth/authorize?response_type=code&client_id=testclient&redirect_uri=/oauth/receivecode&state=xyz

    I get an error message saying

    404 not found

    https://i.stack.imgur.com/1Qpnz.png

    opened by JonnyD 1
  • Execute apigility in subfolder

    Execute apigility in subfolder

    Hi,

    I need to run my Apigility application in a sub-folder, as follows in the structure below.

    Obs.: I am using IIS ...

    • All application - app1 - app2 - apigility

    Other services... http://localhost:8080/app1/ http://localhost:8080/app2/

    My apigility ... http://localhost:8080/wservice/

    tks ,

    opened by rafaelbffarias 1
  • DbConnectedResource create method return nothing

    DbConnectedResource create method return nothing

    In zend-apigility\zf-apigility-skeleton\vendor\zfcampus\zf-apigility\src\DbConnectedResource.php create function has no return data if the collection identifier field is not an auto increment value or there is no auto increment field in table.

    $id = $this->table->getLastInsertValue();
    return $this->fetch($id);
    

    In my case I have no auto increment field so $id = 0 and the fetch method return "no item found".

    My solution:

    //$id = $this->table->getLastInsertValue(); return $this->fetch($data[$this->identifierName]);

    opened by Hoszi 1
  • New to Apigility, stuck in

    New to Apigility, stuck in "Getting Started", help .......

    Hello guys, I am new to Apigility and get stuck in first API in "Getting Started".

    Created 'Status' API, created 'Ping' service. When creating field "ack", it told "Error saving field" and "Error during the API communication", I couldn't create a new field. I tried deleting "Status" API, but it told me "Error during the delete of the API" and "Unable to delete API".

    Anyone has some ideas about the issue?

    My platform: Win7+IIS7.5+PHP7.0.8, virtual host on the local machine. Installing Apigility-skeleton 1.4.1 by Composer. Setup development mode; no opcode cache, disabled php display_error; full control to "config" and "module" folders.

    opened by peopzen 6
Releases(1.5.2)
  • 1.5.2(Jan 9, 2019)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #168 fixes file permissions of the /var/www folder when using Vagrant, setting them to the www-data user.
    Source code(tar.gz)
    Source code(zip)
  • 1.5.1(Aug 15, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #165 updates the composer.lock by running composer install using a PHP 5.6 release. This was done as the 1.5.0 release was made using a PHP 7.1+ binary, and thus installed versions of dependencies that were compatible with those release - but not with 5.6. Once a release is made with this patch, users on PHP 5.6 will be able to install the skeleton again.

      However, this means that PHP 7.1+ users will need to execute the following after an initial skeleton install in order to get newer versions of libraries compatible with 7.1:

      $ rm -Rf composer.lock vendor
      $ composer install
      
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.5.1.tgz(4.84 MB)
    zf-apigility-skeleton-1.5.1.zip(7.32 MB)
  • 1.5.0(May 8, 2018)

    Added

    • #159 adds a development requirement on zendframework/zend-test, ensuring users have the ability to run existing unit tests, as well as write and execute new ones out of the box.

    Changed

    • #164 updates all dependencies to versions that will work with PHP 7.2, where possible.

    • #154 modifies the config/autoload/.gitignore rules to omit *.local-development.php files.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.5.0.tgz(4.85 MB)
    zf-apigility-skeleton-1.5.0.zip(7.44 MB)
  • 1.4.2(Mar 28, 2018)

  • 1.4.1(Oct 17, 2016)

    Added

    • Nothing.

    Changes

    • #146 updates the Vagrant configuration to use bento/ubuntu-16.04 as its base.
    • #147 updates the minimum supported versions of the following dependencies:
      • zend-component-installer: 0.5.0
      • zf-apigility-documentation: 1.2.3
      • zf-apigility-admin: 1.5.9
    • #148 updates the public/index.php to allow intercepting calls to it for enabling and disabling development mode (e.g., php public/index.php development enable). These calls now proxy to the official zf-development-mode scripts. The change was made to allow backwards compatibility in existing toolsets such as Zend Studio, which would enable development mode when invoking the admin GUI.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #136 fixes the shipped error view scripts to accommodate PHP 7 Throwable instances.
    • #138 fixes the Docker configuration of the Apache virtual host such that it will work correctly.
    • #145 adds a missing bootstrap directive to the shipped phpunit.xml.dist.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.4.1.tgz(6.81 MB)
    zf-apigility-skeleton-1.4.1.zip(8.84 MB)
  • 1.4.0(Aug 15, 2016)

    This version bumps the minimum supported PHP version to 5.6.

    It incorporates the following components and modules at the specified versions; these versions likely contain bugfixes, and, if noted, additional features. Additional Zend Framework components are also present, but not noted here.

    • zendframework/zend-component-installer: 0.3.0
    • zendframework/zend-developer-tools: 1.1.0
    • zfcampus/zf-api-problem: 1.2.1
    • zfcampus/zf-apigility: 1.3.0
      • Support in ZF\Apigility\Application for handling PHP 7 Throwables.
    • zfcampus/zf-apigility-admin: 1.5.6
      • Extracts all factories defined in the Module class to their own classes.
      • Extracts all listeners defined in the Module class to their own classes.
      • Adds a patchList() stub to the REST resource class template, so that it is present by default.
      • Adds support for working with modules using PSR-4 directory format, and the ability to generate PSR-4-style modules.
      • Adds a vendor script, apigility-upgrade-to-1.5, for upgrading an existing Apigility application so that it may use Zend Framework component v3 releases.
      • Adds the ability to generate all configuration files using short array syntax and ::class notation.
      • Adds a new API endpoint for reporting the current Apigility skeleton version.
    • zfcampus/zf-apigility-admin-ui: 1.3.7
      • Displays the current Apigility skeleton version as returned by the zf-apigility-admin API.
      • Uses full controller service names when interacting with the zf-apigility-admin API; this resolves some lingering UI issues due to version mismatch.
      • Adds a "field type" input to new field entries, allowing you to provide this information via the UI (previously the information could only be provided by manually updating configuration files). This allows communicating field type information to documentation systems such as Swagger.
      • Numerous UI fixes, particularly with regards to sidebar behavior.
    • zfcampus/zf-apigility-documentation: 1.2.2
      • Adds support for displaying documentation of APIs in nested PHP namespaces.
      • Adds support for transforming Markdown documentation to HTML, and enables it by default.
      • Displays field types, if provided, by default.
    • zfcampus/zf-apigility-provider: 1.2.0
      • Deprecates the Module class. You no longer need to list the ZF\Apigility\Provider module in your application module configuration.
    • zfcampus/zf-asset-manager: 1.1.1
      • New in this version. Uses configuration from rwoverdijk/assetmanager to expose asset directories in the document root of your application. It acts as a Composer plugin, and copies configured asset directories under your public/ directory, adding an entry to that directory's .gitignore file to prevent checking those files into version control. Updates to modules are honored, and removal of a module will remove the files from your source tree.
    • zfcampus/zf-composer-autoloading: 1.0.0
      • New in this version. Provides a vendor binary for adding an autoloading entry to your Composer configuration for the module you specify, and then updates autoloading rules locally.
    • zfcampus/zf-configuration: 1.2.1
      • Adds a new configuration switch, zf-configuration.class_name_scalars, allowing you to configure whether or not generated configuration will use ::class notation.
    • zfcampus/zf-console: 1.3.0
      • Adds the ability to substitute your own dispatcher via the ZF\Console\DispatcherInterface
      • Adds the ability to disable output of the application banner.
      • Adds the ability to compose a container-interop container with the dispatcher, which allows providing service names as console handlers.
      • The exception handler now catches PHP 7 Throwable instances as well.
    • zfcampus/zf-content-negotiation: 1.2.2
    • zfcampus/zf-content-validation: 1.3.4
      • Adds support for mapping input filters to GET requests. This feature is not yet supported in the admin UI, however.
    • zfcampus/zf-deploy: 1.2.0
    • zfcampus/zf-development-mode: 3.0.0
      • This new release now ships as a standalone vendor binary, instead of using the deprecated MVC <-> Console integration.
    • zfcampus/zf-hal: 1.4.2
      • Adds an interface, concrete classes, and configuration for allowing alternate "self" and generic link generation strategies. As such, usage of the server url and url helpers with the Hal plugin is now deprecated.
      • Adds service factories for the two link extraction services, allowing the ability to provide alternate facilities if needed.
      • Adds a new method to the Hal plugin, resetEntityHashStack(); this can be used when rendering multiple responses or payloads within the same request cycle to allow re-use of the same entity instances.
    • zfcampus/zf-mvc-auth: 1.4.2
    • zfcampus/zf-oauth2: 1.4.0
      • Adds support for the ext/mongodb extension.
      • Adds token revocation suport.
    • zfcampus/zf-rest: 1.3.1
    • zfcampus/zf-rpc: 1.3.0
    • zfcampus/zf-versioning: 1.2.0

    Please read the migration documentation for more details on upgrading.

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.4.0.tgz(6.69 MB)
    zf-apigility-skeleton-1.4.0.zip(8.71 MB)
  • 1.3.3(Mar 16, 2016)

  • 1.3.2(Jan 27, 2016)

    Incorporates the following fixes from zf-apigility-skeleton:

    Additionally, the following modules have updates incorporated in this release:

    • zf-development-mode updated to 2.1.2; brings in fixes for configuration cache settings when switching between development and production modes.
    • zend-apigility-admin 1.4.1 fixes an issue in the RpcServiceModel to ensure that a correct pattern is generated when fetching a service by name.
    • zend-apigility-admin-ui 1.2.2 fixes a number of issues discovered, including:
      • DB Autodiscovery was failing due to inability to properly select the DB adapter name.
      • Custom authentication adapters are now displayed.
      • The regex for validating custom content-types was fixed to ensure it only allows valid MIME type specifications.
      • Fixes validation for REST and RPC service names, raising a warning on invalid input.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.3.2.tgz(8.75 MB)
    zf-apigility-skeleton-1.3.2.zip(13.93 MB)
  • 1.3.1(Jul 23, 2015)

    • zfcampus/zf-oauth2#112 fixes a parse error in the receive code template, and updates the cURL examples on that page to use the current request scheme.
    • Fixes for AG2015-01, which patch a user spoofing vector in zf-oauth2.
    • zfcampus/zf-mvc-auth#94 fixes HTTP authentication to ensure that omitting an Authorization header no longer results in a 401 status, and instead falls back to using the GuestIdentity as it did prior to 1.1.0.
    • zfcampus/zf-apigility-admin#305 and zfcampus/zf-apigility-admin-ui#69 allow DB adapters that do not support metadata features to be used for DB-Connected REST services.
    • #105 updates the Vagrant setup to ensure it includes PHP 5.6, allowing it to work with versions 1.3+.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.3.1.tgz(8.26 MB)
    zf-apigility-skeleton-1.3.1.zip(13.44 MB)
  • 1.2.1(Jul 23, 2015)

    • zfcampus/zf-oauth2#112 fixes a parse error in the receive code template, and updates the cURL examples on that page to use the current request scheme.
    • Fixes for AG2015-01, which patch a user spoofing vector in zf-oauth2.
    • zfcampus/zf-mvc-auth#94 fixes HTTP authentication to ensure that omitting an Authorization header no longer results in a 401 status, and instead falls back to using the GuestIdentity as it did prior to 1.1.0.
    • zfcampus/zf-apigility-admin#305 and zfcampus/zf-apigility-admin-ui#69 allow DB adapters that do not support metadata features to be used for DB-Connected REST services.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.2.1.tgz(6.29 MB)
    zf-apigility-skeleton-1.2.1.zip(9.79 MB)
  • 1.3.0(Jul 15, 2015)

    This version bumps the minimum supported PHP version to 5.5.

    It incorporates the following modules at the specified versions; if no changes are specified, assume that the only changes were updating the minimum supported PHP version.

    • zfcampus/zf-apigility: 1.2.1
    • zfcampus/zf-apigility-admin: 1.3.0
    • zfcampus/zf-apigility-admin-ui: 1.2.0
    • zfcampus/zf-apigility-documentation: 1.1.0
    • zfcampus/zf-apigility-documentation-apiblueprint 1.1.0
    • zfcampus/zf-apigility-documentation-swagger: 1.1.0
    • zfcampus/zf-apigility-provider: 1.1.0
    • zfcampus/zf-api-problem: 1.1.0
    • zfcampus/zf-configuration: 1.1.0
    • zfcampus/zf-console: 1.2.0
    • zfcampus/zf-content-negotiation: 1.1.0
    • zfcampus/zf-content-validation: 1.2.0
    • zfcampus/zf-deploy: 1.1.0
      • #31 improves the check for ZF2 applications.
      • #33 fixes the usage of the --modules option to target only application-specific modules (not installed 3rd party modules).
      • #43 updates the minimum PHP version to 5.5.
    • zfcampus/zf-development-mode: 2.1.0
    • zfcampus/zf-hal: 1.2.0
    • zfcampus/zf-http-cache: 1.1.0
    • zfcampus/zf-mvc-auth: 1.3.0
    • zfcampus/zf-oauth2: 1.3.0
    • zfcampus/zf-rest: 1.2.0
    • zfcampus/zf-rpc: 1.2.0
    • zfcampus/zf-versioning: 1.1.0
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.3.0.tgz(7.14 MB)
    zf-apigility-skeleton-1.3.0.zip(11.25 MB)
  • 1.2.0(Jul 15, 2015)

    This release includes the following changes and fixes:

    • #87 Fix incorrect closing tag in layout
    • #88 Change order in which zf-oauth2 and zf-mvc-auth are loaded, and adds global configuration to override the ZF\OAuth2\Service\OAuth2Server factory to ensure the one from zf-mvc-auth is used.
    • #92 Promote zf-development-mode to a production requirement
    • #99 Add Docker environment
    • #98 Separate module list into a config/modules.config.php
    • #100 Use ZF\Apigility\Application instead of Zend\Mvc\Application

    Additionally, it includes the following modules at the following versions, with the specified changes:

    • zfcampus/zf-api-problem: 1.0.3
      • #33 Ensure non-HTTP exception codes are cast to 500
    • zfcampus/zf-apigility: 1.1.0
      • #120 Extend Zend\Mvc\Application to catch route event exceptions
    • zfcampus/zf-apigility-admin: 1.2.0
      • #279 Do not save an empty DSN to configuration
      • #288 digest_domains option is now required when creating HTTP Digest authentication
      • #289 Write application module list to a separate file to prevent evaluation and subsequent writing of application.config.php
      • #292 Sort services by name in API
      • #297 Return 409 status when attempting to create a REST service that already exists
      • #299 Ensure module is PHP 5.3 compatible
      • #300 Raise 409 status if new service route conflicts with existing route
    • zfcampus/zf-apigility-admin-ui: 1.1.5
      • #45 digest_domains option is now required when creating HTTP Digest authentication
      • #61 Ensure file upload flag is sent properly to the API
      • #63 Ensure the API version is sent when fetching authorization details
      • #63 Improved text in delete filter modal
      • #66 Strip error message from update filter payload when empty
    • zfcampus/zf-apigility-documentation: 1.0.6
      • #29 QA toolchain updates
    • zfcampus/zf-apigility-provider: 1.0.2
      • #7 QA toolchain updates
      • #5 Updated requirements section in README.md
    • zfcampus/zf-configuration: 1.0.3
      • #11 QA toolchain updates
    • zfcampus/zf-console: 1.1.1
      • #22 Do not call cli_set_process_title on Mac OS X
      • #24 Set minimum zend-console version to 2.3, since we depend on features of 2.3+
    • zfcampus/zf-content-negotiation: 1.0.8
      • #40 Better trimming of whitespace around JSON before deserialization
      • #42 Return 400 status when multipart body cannot be parsed
      • #43 Refactor listener factories for better maintainability
    • zfcampus/zf-content-validation: 1.1.1
      • #50 QA toolchain updates
    • zfcampus/zf-deploy: 1.0.5
      • #42 Improved error reporting and status codes
      • #41 Updated QA toolchain
      • #35 Fix directory separator issue in ZIP packages created under Windows
    • zfcampus/zf-development-mode: 2.0.6
      • #11 Updated QA toolchain
    • zfcampus/zf-hal: 1.1.1
      • #100 Re-instate renderEntity.post event
      • #102 Eliminate double-rendering of links
      • #106 Improved testing of HalJsonRenderer
    • zfcampus/zf-mvc-auth: 1.2.0
      • #77 Merge default zf-oauth2 config when creating adapters
      • #80 Remove obsolete bin entry in composer.json
      • #83 Use oauth2-server-php response status if invalid or missing credentials are presented, or invalid for scope
      • #85 Allow custom HTTP authentication resolvers via configuration.
      • #90 Only attach listeners during HTTP requests
    • zfcampus/zf-oauth2: 1.2.0
      • #98 Update HTTPie examples in README.md
      • #100 Add support for oauth2-server-php unset_refresh_token_after_use option
      • #108 Fix content-negotiation configuration for OAuth2 controller
    • zfcampus/zf-rest: 1.1.1
      • #75 Return 400 status for non-array values passed to replaceList()
      • #78 Handle exceptions from Paginators for non-integer page numbers
      • #80 Extract method triggerEvent() for triggering events with common short-circuit callbacks
      • #81 Extract methods createApiProblemFromException(), isPreparedResponse(), createHalEntity(), createHalCollection() to reduce duplication
      • #83 Return 400 status for out of range page size query string parameters
      • #84 Allow returning zf-hal entities and collections from zf-rest resource listeners.
      • #85 Return 400 status for non-array values passed to patchList()
    • zfcampus/zf-rpc: 1.1.0
      • #7 Allow pulling RPC callbacks via the ControllerManager or ServiceManager
    • zfcampus/zf-versioning: 1.0.3
      • Updated dependencies to ensure PHP 5.3 compatibility.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.2.0.tgz(6.29 MB)
    zf-apigility-skeleton-1.2.0.zip(9.79 MB)
  • 1.1.1(Apr 21, 2015)

    This is the first maintenance release in the 1.1 series, and provides a number of fixes based on feedback provided after the 1.1.0 release last week. Changes include:

    • zf-apigility-admin 1.1.2
      • #285 Fix issue with path to zfdeploy.php preventing packaging from working.
      • #284 Updates to Doctrine integration to expose ODM connections and entities.
    • zf-apigility-admin-ui 1.1.4
      • #35 Reinstate the "generate from config" functionality in the service documentation screens.
      • #36 Fix rendering issues in service operations of documentation.
      • #37 Reintroduce toggle buttons for boolean filter and validator options.
      • #38 Add labels around HTTP method options, in order to allow clicking the label to toggle the checkbox.
      • #39 Add "type to select" features to the filter, validator, and hydrator drop-downs. This provides in-list search to provide a list of matches to the user, based on what was typed.
      • #40 Fixes how content negotiation selectors are sent to the admin API, ensuring appropriate values are stored.
      • #41 Implemented "growl"-style notifications for most API operations to indicate success and failure status.
    • zf-apigility-documentation 1.0.5
      • #27 Fix rendering issues due to non-existent array indices.
    • zf-apigility-documentation-swagger 1.0.4
      • #11 Fix Service::toArray() to fetch fields from the default input filter.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.1.1.tgz(6.25 MB)
    zf-apigility-skeleton-1.1.1.zip(9.74 MB)
  • 1.1.0(Apr 16, 2015)

    Welcome to the first release in the 1.1 series!

    This release features a completely rewritten UI! We expect it to resolve many of the performance issues and edge cases observed previously by users; it also simplifies the most-common workflows and puts more information at developers' fingertips than previously. On top of that, it's now fully responsive; you can even use it on your smartphone!

    The major features in this release include:

    • Doctrine-Connected REST service creation (if the zfcampus/zf-apigility-doctrine module is present)
    • Database Autodiscovery, which improves on the DB-Connected services by allowing you to choose all tables you wish to expose as services, and to provide basic validations based on column types.
    • Addition of a Packaging service to the Admin API and UI to simplify and automate creation of deployment packages.
    • Apigility now supports multiple authentication adapters for each type supported, and per API authentication (vs per-application, as supported in 1.0).

    Other features:

    • API modules can now use PSR-4 directory structures. zf-apigility-admin still creates modules using PSR-0, but will detect PSR-4 directory structures and work correctly with them (including for code generation purposes).
    • A new module, zf-http-cache, is available for integrating should you wish to add HTTP cache features to your API.

    The following modules were tagged at 1.1.0, with features as noted below.

    • zf-apigility-admin
      • Integration of zf-apigility-doctrine support in UI
      • Addition of DB Autodiscovery feature for creation of REST services
      • #246 deprecated PUT for authorization service, implemented PATCH
      • #266 New API service for creating a deployment package
      • #262 PSR-4 module structure support
      • #271 Per-API authentication configuration
    • zf-apigility-admin-ui
      • Completely rewritten UI, with new features including:
        • Per-API authentication
        • Packaging
        • Doctrine-Connected REST services
        • DB Autodiscovery for REST service creation
    • zf-console
      • #18 ability to remove a route
      • #19 autodetect console adapter if not passed to constructor
    • zf-content-validation
      • #38 adds EVENT_BEFORE_VALIDATE to allow manipulating an input filter prior to validation
      • #34 allow specifying custom HTTP methods that do not have message bodies
      • #29 allow opting in, by controller service name, to inject the body parameters with the validated, filtered values of validation
      • #41 remove the InputFilterAbstractFactory in favor of the version shipped in ZF 2.4
    • zf-hal
      • #79 "post" events for renderEntity and renderCollection
      • #91 only export public members of objects when no hydrator present
    • zf-mvc-auth
      • #60 allow multiple http and/or oauth2 adapters, and allow authenticating per-API instead of per-application
    • zf-oauth2
      • #70 configurable grant types
      • #72 allow returning the OAuth2 response format instead of Problem Details for error conditions
      • #83 enable the JWT grant type
      • #87 introduction of User ID providers, to map a token to a user/identity
      • #89 introduction of IbmDb2-specific OAuth2 storage adapter
    • zf-rest
      • #65 removes setTerminal() call on view model in RestController, to allow using within templated systems
      • #71 syncs RestController::deleteList() with Zend\Mvc\Controller\AbstractRestfulController::deleteList() from ZF 2.4
      • #68 allow returning a Response from a Resource listener

    Acknowledgements

    We had a number of quite significant contributions to this release. While I'd like to name everyone who contributed, the following individuals stand out in particular:

    • Tom Anderson, who contributed the zf-apigility-doctrine module.
    • Julien Guittard, who did the UI integration (and much of the Admin API work) for the Doctrine-Connected REST resources, developed the DB Autodiscovery feature, and who was tireless in his testing of the UI integrations.
    • Corentin Larose, who contributed zf-http-cache.
    • Steve Rhoades, who contributed the PSR-4 support.
    • Enrico Zimuel, who rewrote the UI for 1.1.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.1.0.tgz(6.13 MB)
    zf-apigility-skeleton-1.1.0.zip(9.71 MB)
  • 1.0.5(Apr 16, 2015)

    This is the final release in the 1.0 series, and primarily contains a number of incremental improvements, as broken down by module below.

    • zf-apigility 1.0.3
      • documentation updates
    • zf-apigility-admin 1.0.5
      • UI code is now in its own repo
      • #226 (name normalization for URIs)
      • #249 (validation of content_name for content-negotiation service)
      • #252 (implementation of input filter for content negotiation rules)
      • #253 (optional selectors for content negotiation creation)
    • zf-apigility-admin-ui 1.0.7
      • #6 (fixes /ui route)
    • zf-apigility-doctrine 0.3.4
      • Doctrine Autodiscovery features
      • PHP 5.3 compatibility
      • Ensure service_name is available in configuration
    • zf-apigility-documentation 1.0.4
      • #17 (support for documenting field types)
      • #20 (support for method-specific fields)
      • #24 (nested fields display)
      • #26 (support for PHP 5.3)
    • zf-apigility-documentation-swagger 1.0.3
      • #9 (support for documenting field types)
    • zf-apigility-skeleton 1.0.5
      • #68 (added config and module caching by default; disabled in development)
    • zf-api-problem 1.0.2
      • documentation fixes
    • zf-configuration 1.0.2
      • documentation fixes
      • CS fixes
    • zf-console 1.0.4
      • #16 (automatic indentation on help screens)
    • zf-content-negotiation 1.0.4
      • #25 (fix to allow multiple upload files to be filtered)
      • #25 (fix to allow multiple upload files to be filtered)
      • #29 (allow validating DELETE requests to collections)
      • #32 (allow registering the CotnentTypeListener as a service)
    • zf-content-validation 1.0.3
      • #21 (created getInputFilter() controller plugin for retrieving input filter in RPC services)
      • #31 (ensure input filter abstract factory composes registered filter and validator plugin managers into input filter factory)
    • zf-deploy 1.0.4
      • #31 (support for PHP 5.4 short-array syntax when detecting zf2 applications)
      • #33 (do not overwrite non-API modules when creating a deployment package with select modules)
    • zf-development-mode 2.0.5
      • CS, Quality Assurance tooling, and doc fixes
      • #10 Remove cached module configuration when enabling development mode.
    • zf-hal 1.0.5
      • #59 (better injection of Hal plugin into helper plugin manager)
      • #60 (move all factories into classes)
      • #63 (allow generating URLs behind proxies)
      • #68 (cache value from serverUrl() helper)
      • #69 (use hydrator map when possible - performance improvement)
      • #86 (allow auto-invokable hydrators)
      • #88 (circular dependency detection during entity extraction)
    • zf-mvc-auth 1.0.3
      • #38 (created getIdentity() controller plugin for use in RPC services)
      • #40 (added configurable HTTP auth resolver - allows specifying file or Apache resolver via configuration)
      • #46 (allow using configured ZF\OAuth2\Service\OAuth2Server service instead of building from configuration)
      • #57 (inject current HTTP request headers into OAuth2\Request instance) - zf-oauth2 1.0.3
      • #61 (document pgsql-specific DDL)
      • #62 (better options merging order, to allow setting common defaults and allow overriding per adapter)
      • #65 (allow configuration-driven MongoClient options)
      • #67 (allow configuration of server storage)
      • #80 (properly handle null message bodies)
    • zf-rpc 1.0.2
      • documentation fixes
    • zf-versioning 1.0.2
      • documentation fixes
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.5.tgz(6.63 MB)
    zf-apigility-skeleton-1.0.5.zip(10.12 MB)
  • 1.0.4(Aug 13, 2014)

    We are pleased to announce the immediate availability of Apigility 1.0.4!

    • https://apigility.org/download

    This is our fourth maintenance release of Apigility.

    IBM i Support

    This release contains a number of fixes to ensure the ability to use Apigility on IBM i. Among them:

    • We are pinning support to Zend Framework 2.3.2 and above, which contains updates supporting DB2:
      • Full transaction support.
      • Fixed LIMIT support, allowing for paginated DB result sets.
      • Fixes to database-backed authentication
    • The ability to specify database driver options via the Admin UI. Most DB2 connections need additional driver options specified, and you can now do so via the UI.

    UI Improvements

    One lingering issue we've had reported is an error when creating APIs: the UI reports an error, but the API has been created. We made several patches that, in aggregate, should resolve these issues going forward:

    • We discovered that our promise chains in the Admin UI were not optimally constructed, and could potentially raise errors under the appropriate conditions; these have been fixed.
    • We introduced comprehensive cache control headers to prevent client-side caching of Admin API calls.
    • We introduced a timeout between successful completion of API creation and deletion calls, and subsequent fetching of the API list from the Admin API. In working with Julien Guittard, we were able to find an optimal timeout that resolves the issue.

    Additionally, for those users using Apache to serve the Admin UI and Admin API, we have stopped using backslashes in URI identifiers (Apache rejects URI-encoded slashes by default).

    Other fixes were also made that are detailed under the "zf-apigility-admin" header below.

    Documentation fixes

    zf-apigility-documentation was not using the correct configuration key to discover input filters, which meant it was not reporting fields at all. This had further implications for zf-apigility-documentation-swagger, which was then unable to expose models based on those fields. This situation is now resolved.

    Collections

    While Apigility has supported retrieving collections in REST services, creating, replacing, updating, or deleting them has been an exercise left to the developer previously. With this release, field definitions can now be used to validate the items passed to collections, giving collections first-class support.

    Console

    zf-console was extensively updated, with many contributions and ideas from Zend's Slavey Karadzhov. These include:

    • Simplification of mapping the command name to the route. By default the command name is considered the first argument of the route now.
    • Command handlers may now be specified in the configuration via the handler key for a command.
    • A number of useful CLI-specific filters are now provided, including an Explode filter (split comma or other delimited arguments to an array), a QueryString filter (specify arguments in query string format), and a Json filter (specify arguments in JSON).
    • Better error handling and error reporting.
    • The ability to generate autocompletion scripts for your CLI commands.

    zf-console is shaping up as a capable microframework for CLI commands!

    Thank You!

    Many thanks to everyone who contributed fixes, big or small, towards this release!

    Issues closed:

    zf-apigility-admin

    zf-apigility-documentation

    zf-apigility-documentation-swagger

    zf-apigility-skeleton

    zf-console

    zf-content-validation

    zf-deploy

    zf-hal

    zf-mvc-auth

    deny_by_default inverts permission rules Support for OAuth2 Token in Query String / POST Body

    zf-oauth2

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.4.tgz(6.54 MB)
    zf-apigility-skeleton-1.0.4.zip(9.99 MB)
  • 1.0.3(Jun 5, 2014)

    This is our third maintenance release of Apigility, and the first containing security fixes; read on for more information.

    Security Fixes

    We were notified by Stefano Torresi of a potential security vector in ZF\Apigility\DbConnectedResource. While the create() method of that class pulls data from the composed input filter, if present, the patch() and update() methods were not, making it possible for an attacker to send unwanted data to the API service.

    We have updated the class to pull from the composed input filter, if present, for each of the create(), patch(), and update() methods.

    If you use DB-Connected REST resources in Apigility, we strongly recommend updating immediately. You can do so by running composer update inside your application.

    Deployment Fixes

    We were notified that the logic for finding a Composer executable in zf-deploy would fail in some situations. A fix was contributed that better resolves the path to the executable, particularly in situations where a composer.phar must first be downloaded.

    Additionally, in reviewing this fix, Enrico Zimuel noted that we needed test coverage for most of the ZFDeploy functionality; we now have a comprehensive set of tests, all passing!

    Documentation Fixes

    Kaloyan Raev noted that the HTML documentation does not render properly under Internet Explorer, due to the order in which media type selectors are matched. A swap in the order fixes the situation, and continues to work as expected under other browsers.

    Thank You!

    Many thanks to Stefano Torresi for working with us on the DB-Connected security issue, to Kaloyan Raev for his assistance with zf-deploy and the documentation, and to Enrico Zimuel, for the huge amount of testing he added to zf-deploy!

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.3.tgz(6.12 MB)
    zf-apigility-skeleton-1.0.3.zip(9.53 MB)
  • 1.0.2(Jun 4, 2014)

    This is our second maintenance release of Apigility, fixing a number of issues, and providing significant improvements for file upload capabilities.

    Upload Support

    Uploads were possible before this release, but were difficult to properly enable. Additionally, PATCH and PUT requests required manually handling the file uploads, as PHP does not natively support file uploads for those request methods; the Zend Framework 2 InputFilter component, because it utilizes PHP's native support for validating that an upload completed and for moving an upload file to a new location, also could not deal with these methods.

    This release makes the following changes in order to facilitate file uploads via your Apigility API:

    • Content validation was altered to merge file upload data, when present, with the submitted API fields.
    • The Admin UI now allows you to mark a field as representing a file upload; this ensures that content validation will work properly, as content validation differs for file uploads.
    • The content negotiation module now provides emulation for PHP's file upload support when receiving PATCH and PUT requests, ensuring that the files are uploaded in the same manner, cleaned up post-request, and passed to validation properly. You should notice no difference between POST, PUT, or PATCH requests when performing file uploads, whether a single or multiple files are provided.

    File uploads are only done using the multipart/form-data media type. You will need to add that media type to the content negotiation whitelist if you plan to perform file uploads.

    If you have further questions, you can consult the documentation.

    Changelog

    While upload support is the major feature of this release, we fixed many other issues.

    General

    • All repositories have updated composer.json files that properly define the two branch aliases for the master and develop branches.
    • All repositories have updated README.md files that provide a "Requirements" section linking to the composer.json file.

    zf-apigility-admin

    zf-apigility-documentation

    zf-apigility-skeleton

    zf-content-negotiation

    zf-content-validation

    zf-deploy

    zf-hal

    zf-oauth2

    Roadmap

    Many thanks for all the great issue reports and discussions on the mailing list and the various issue trackers!

    We will do additional maintenance releases on an as-needed basis. The next feature release, 1.1, is in development, and includes:

    • Doctrine-Connected REST services
    • Database Autodiscovery for REST services (think of this as DB-Connected that finds all your tables and proposes field configuration for you!)
    • Mongo-Connected REST services
    • HTTP Caching

    We would appreciate any feedback you can provide, either in the mailing lists, in issues, or via comments on associated pull requests.

    Stay tuned!

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.2.tgz(5.84 MB)
    zf-apigility-skeleton-1.0.2.zip(9.17 MB)
  • 1.0.1(May 14, 2014)

    We are pleased to announce the immediate availability of Apigility 1.0.1!

    This is our first maintenance release of Apigility, and features a number of bugfixes reported since the initial release.

    Changelog

    • zf-content-negotiation
      • Removed a conditional in ZF\ContentNegotiation\JsonModel that could never be reached, and which was redundant with the parent class. (#17)
    • zf-apigility-skeleton
      • Added a footer and favicon to the default layout. (#60)
    • zf-apigility-admin
      • Fixed a refresh issue with new RPC services. (#159)
      • Fixed a rendering issue in the navbars when on small screens. (#162)
      • Ensured the <base href> for the admin UI uses a fully-qualified URI, including scheme, host, and port, to ensure assets may be resolved cross-platform. (#164)
      • Added config information for the zend_datacache.apc-compatibility INI setting to the "disable your cache" modal. (#165)
      • Ensured the entity_identifier_name and hydrator_name configuration settings in db-connected configuration are properly synced on updates to DB-Connected REST services. (#166)
      • Ensured that togglable filter option values are saved correctly. (#167)
      • Ensured that available options for the DateTimeFormatter (and several others) are propagated to the Admin UI. (#168)
      • Added a footer, favicon, and a number of documentation links to the Admin UI. (#169)
      • Ensured that the collection_name REST setting can be updated from the Admin UI and API. (#170)

    Changes to Composer configuration

    A user noted that we had two branch-alias sections in each repository. While this did not lead to invalid configuration, it did mean that the latter took precedence of the former, meaning that the only "development" alias we had for mapping the development branch to future 1.1 releases. All repositories have been updated with the 1.0.1 release to fix this situation; all sections now read as the following:

    {
        "extra": {
            "branch-alias": {
                "dev-master": "1.0-dev",
                "dev-develop": "1.1-dev"
            }
        }
    }
    

    Switch to SSL

    apigility.org was originally served over HTTP. However, with the addition of the installer script, we felt it was important to serve the site over SSL. We were not able to do this in time for the 1.0.0 release, but put the functionality in place by the end of last week. Any previous link will now perform a permanent redirect to the SSL version of the site.

    Roadmap

    Many thanks for all the great issue reports and discussions on the mailing list! (We promise we'll get to more of the questions, now that we've dealt with the initial issue reports!)

    We will do additional maintenance releases on an as-needed basis. We already have plans for 1.1, which include:

    • Doctrine-Connected REST services
    • Database Autodiscovery for REST services (think of this as DB-Connected that finds all your tables and proposes field configuration for you!)
    • Mongo-Connected REST services
    • HTTP Caching

    Many of these are near completion already (and primarily by community authors!); we'll be dropping announcements to the mailing lists when they're ready to test.

    Stay tuned!

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.1.tgz(5.80 MB)
    zf-apigility-skeleton-1.0.1.zip(9.33 MB)
  • 1.0.0(May 7, 2014)

    We're happy to announce the immediate availability of Apigility 1.0.0!

    Apigility is the world's easiest way to create robust, well-formed, documented, and secure APIs.

    We've noticed that web development has fundamentally shifted over the past few years. Server side applications that return heavy loads of HTML markup are waning; instead APIs are driving the web. APIs are being used to enable inter-division data exchange. APIs are being used as the building blocks for web applications -- allowing user interface experts the flexibility to change the look and feel of a website with no intervention from the server-side application developers. APIs are driving and empowering the mobile web, allowing creation of both native mobile applications and mobile web applications.

    Apigility exists to allow you to expose your business logic as an API.

    Opinionated

    APIs are not just about tossing around some JSON or XML. They require a ton of architectural decisions every step of the way as you implement the API:

    • How will you handle HTTP method negotiation?
    • How will you handle content negotiation?
    • How will you handle authentication?
    • How will you handle authorization?
    • How will you handle input validation?
    • What representation format will you use?
    • How will you represent errors?
    • How will you document your API?

    Most of these questions have no single, correct answer. Many standards, proposals, and drafts exist for all aspects of APIs. As a developer, you have to wade through them and choose which you will use, and how you will put them together.

    In short, when developing an API, you often spend an equal or greater amount of time developing the architecture for the API as you would writing the code you want to expose in the first place.

    Apigility is opinionated for you, and provides a flexible and robust engine that answers these questions:

    • application/hal+json is used for the representation format (but you can add your own representations if you really want).
    • application/problem+json is used for representing errors.
    • HTTP method negotiation is handled early, returning appropriate response status codes and headers when invalid methods are detected. Support for OPTIONS requests is built in.
    • Content negotiation is handled early, returning appropriate response status codes and headers when we cannot return an appropriate representation, or cannot understand the data provided to the application.
    • Authentication is handled early, returning appropriate response status codes and headers when invalid credentials are detected. We provide HTTP Basic, HTTP Digest, and OAuth2 support out-of-the-box, but provide a flexible, event-driven system for implementing or integrating your own authentication systems.
    • Authorization is handled early, returning appropriate response status codes and headers when access is not allowed. We provide an ACL-based system that can be easily extended to provide user-specific permissions as well as an event-driven system for implementing or integrating your own authorization systems if needed.
    • Input validation is handled early, returning appropriate response status codes and error messages when invalid data is detected.
    • Documentation is provided out of the box. We provide HTML, JSON, and Swagger representations; we anticipate adding more in the future. Documentation is generated automatically from your API configuration, and you are able to add descriptions and more detail as desired.

    We make decisions so you don't have to. However, you'll note that we've created flexibility so that if you have an opinion, you can integrate it!

    Interface with your API

    Apigility is not just an engine. Apigility also provides a web-based Admin UI to allow you to quickly create and modify your API and services, set up authentication, create authorization rules, set up validations for incoming data, and write document.

    The Admin UI is built using AngularJS, and is backed by... an API! (We're taking the "API First" mantra very seriously!)

    Get Started in Seconds

    You can install Apigility in seconds; execute the following command in your shell:

    $ curl -sS http://apigility.org/install | php
    

    or, if you don't have curl installed, use the PHP interpreter itself:

    $ php -r "readfile('http://apigility.org/install');" | php
    

    Deploy Anywhere

    Apigility is built on top of Zend Framework 2, and has tools to ensure that the Admin UI is only present in development mode. As such, you can deploy Apigility anywhere you normally deploy PHP applications: a local server, your web host provider, or the cloud.

    We provide a tool, ZFDeploy, to aid in creating deployment packages, including Zend Server ZPK files.

    Modular

    Apigility consists of more than a dozen Zend Framework 2 modules, each doing one specific task in the workflow. As such, you can mix and match these modules in your own ZF2 applications, or even add Apigility to an existing application.

    The Future

    Reaching 1.0 is a huge milestone -- but it's not the end of the road!

    We already have a number of great features waiting in the wings for a 1.1 release: Doctrine-Connected services, Database Autodiscovery, Mongo-Connected services, and HTTP Caching.

    What will you build today?

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.0.tgz(5.79 MB)
    zf-apigility-skeleton-1.0.0.zip(9.32 MB)
  • 1.0.0-beta3(Apr 30, 2014)

    This is our third -- and likely last! -- beta release of Apigility! The features in this release are mainly around stabilization.

    Deployment and Console

    Most of the work we've performed since beta2 was on zf-deploy, our packaging/deployment tool. We made the following changes:

    • First, the tool can now be used both within an application, as well as a standalone phar file. When used as a standalone phar file, you can now self update it with the self-update command; this will check https://packages.zendframework.com/ for any new versions, and, if found, do an "in-place" update of the tool. (Note: the library we use that provides this functionality often emits PHP fatal errors; in practice, however, we've noticed that the process works even when such errors are reported.)
    • Second, we were not happy with the argument handling we were using, nor with the strong coupling of console argument parsing logic with the logic consuming the arguments. We built a small microframework around Zend\Console's RouteMatcher subcomponent that provides more flexibility around argument handling, and are now shipping this in the module zf-console.

    In addition to these architectural changes, we also implemented two new features in the tool:

    • You can specify a directory with the "local" configuration you want to use in the deployment package via the --configs argument.
    • You can specify a directory containing the ZPK skeleton you wish to use when creating a ZPK (Zend Server deployment package); this directory should contain a deployment.xml and any scripts you will be using.

    With these changes, we feel that zf-deploy is ready for inclusion in a stable Apigility release!

    Documentation Updates

    We've received a number of documentation improvements since beta2, and added a few documents as well.

    In particular:

    • An error was spotted in the "HAL for RPC services" recipe that made the code unusable.
    • We've documented how to use the Zend Server SDK to deploy ZPK packages.
    • We've added a recipe for adding Apigility modules to an existing Zend Framework 2 application.
    • We've added documentation on the new zf-console module.

    Beta3 Updates

    In addition to the deployment and console tooling, we made the following changes:

    • We updated the SendResponse listener in zf-api-problem to merge in any headers set in the application response object before sending the API Problem response. This ensures that any previously set headers are also set -- solving several issues observed when using third-party modules for Cross Origin Resource Sharing (CORS), as well as HTTP authentication.
    • The storage adapters we ship with zf-oauth now both allow you to specify configuration via a storage_settings key; this change allows you to specify custom tables for both the PDO and Mongo adapters.
    • We've updated the "api.enable" service to ensure it works with current versions of Apigility (and no longer raises errors!).
    • We no longer display a resource class in the "Source Code" tab of a service if a corresponding class does not exist (e.g., DB-Connected resource classes are virtual services).
    • We've added the option to recursively delete the directory for a service to the Admin API; the Admin UI now presents a checkbox with this option.
    • We've added the option to delete an entire API. By default, this only removes the API's module from application configuration; however, you have the option to recursively delete the API module as well (once again presented in the Admin UI via a checkbox).
    • We now generate factories for RPC controllers and REST resource classes when creating new services. This simplifies the story for dependency injection of these classes.

    Roadmap

    At this time, we feel Apigility has become very stable, and that we have addressed the most pressing usability issues. We anticipate issuing a stable release next week (week of 5 May 2014).

    As noted in previous beta announcements, reaching stability is only the first step, however! Features such as "Doctrine-Connected", "Mongo-Connected", and "DB-Autodiscovery" REST services are already either implemented or will be soon, and we will be debuting these in a 1.1 version in the very near future.

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.0-beta3.tgz(4.63 MB)
    zf-apigility-skeleton-1.0.0-beta3.zip(7.97 MB)
  • 1.0.0beta2(Apr 16, 2014)

    Documentation

    The primary goal of the beta phase for the Zend Framework team is documenting the project. We've made enormous headway at this point, but we'll let you be the judge of that; visit the documentation yourself!

    Among topics covered:

    • A "Getting Started" guide, and a companion, "REST Service Tutorial".
    • An API Primer
    • Chapters on Authentication/Authorization, Content Validation, and the Documentation features.
    • A module-by-module reference guide, detailing configuration options.

    New Features

    While the beta cycle is primarily around stabilizing the API and Admin UI, we decided one new feature warranted inclusion in version 1: a packaging/deployment tool, zf-deploy.

    This tool allows you to create packages from your Apigility -- or any ZF2 application -- for deployment. Formats supported include zip, tar, tgz, and zpk (the Zend Server deployment package format). We plan to integrate support for deploying zpk packages soon as well.

    Beta2 Updates

    Polishing, polishing, polishing was our mantra for beta2. This included incorporating user feedback, but also scrutinizing the UI and code for consistency issues.

    UI Updates

    Following beta1, we had a number of complaints about UI responsiveness, particularly around the "Fields" screen. We did some analysis of the UI, and a lot of work around dynamically loading and unloading DOM in the admin based on what should be visible. As a result, we were able to significantly improve responsiveness. There may be more work to do, but early reports indicate that the changes make the Admin UI usable in situations that previously crashed the browser.

    In addition to the performance improvements, we made the following updates:

    • On the "Authorizations" screen for each API, if no authentication is currently configured, we display a message to this effect, and link to the authentication screen. Unfortunately, in beta1, that link was invalid; we've fixed this.
    • The "Fields" tab received a slight overhaul. We noticed that items with toggles displayed "Yes/No" terminology, but "On/Off" for the actual form input; these now use "Yes/No" verbiage consistently. The "Help" screen could not be dismissed with the <Esc> key; it now can. Previously, when hitting <Enter> from the "Create New Field" text input, it would raise the "Help" screen; it now properly creates the new field. The "Description" field was moved to the first option displayed for each field, to promote documentation of fields. We also added a "Validation Failure Message" field to allow specifying a unified error message on failed validation (vs. one or more per validator); we also ensured that "blanking" out the data in this field will remove any such message previously set. Finally, filters are now listed before validators, to signal the order in which validation operations occur (filtering/normalization occurs before validation).
    • The "Source Code" tab was not properly generating links for files; we've fixed this in beta2.

    Engine Updates

    A few improvements were made to the API engine itself:

    • The UnauthorizedListener registered by the zf-apigility module was not registering headers set by the zf-mvc-auth module, meaning that the WWW-Authenticate header was not propagating. This has been corrected.
    • We modified ZF\ContentNegotiation\JsonModel to check for json_encode() errors, and to raise an exception when one is detected. This prevents situations where an empty response is returned on inability to serialize to JSON.
    • zf-apigility-documentation-swagger was not returning a Content-Type header value of application/vnd.swagger+json; it now does.
    • We fixed the bcrypt cost in zf-oauth2 to use the defaults from Zend\Crypt.
    • We updated the OAuth2 database schema in zf-oauth2 to match that of the upstream oauth2-server-php package.
    • We now inject the ZF\Rest\ResourceEvent with the current MVC request object; you can retrieve it from within your resource class using $this->getEvent()->getRequest(). This will give you access to HTTP request headers, query string arguments, etc.
    • We no longer allow multiple "self" relational links in zf-hal.
    • When specifying route parameters for a zf-hal metadata map, you can now use a PHP callable as the value; zf-hal will invoke that callable with the object for which a link is being generated in order to get the value for that route parameter. This is particularly useful for deterimining identifiers for parent resources.
    • We moved the zf-apiglity-welcome requirement to be a development-only requirement.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.0beta2.tgz(4.38 MB)
    zf-apigility-skeleton-1.0.0beta2.zip(7.63 MB)
  • 1.0.0beta1(Mar 24, 2014)

    This is the first beta release for Apigility. From this point forward, we will be keeping backwards compatibility between versions. New features will be targetted for version 1.1.0, with bugfixes and security fixes targetted for the upcoming stable release and any subsequent maintenance releases.

    New Features

    All Apigility modules were updated to use a PSR-4 structure and autoloader. This flattens the packages significantly, and also allows simplification of the PHPUnit test runner. A PSR-4 variant of the ZF2 StandardAutoloader, ZF\Apigility\Autoloader, was created to provide true PSR-4 autoloading, including the ability to have underscores (_) in class names, which has been a common feature request. ZF2 Module classes created for new API modules now use the new autoloader for loading classes inside the module.

    All modules were added to Travis-CI, giving us continuous integration going forward.

    With the release of Zend Framework 2.3.0, we were able to update the ZF2 dependency to remove the -dev stability marker; this also means that packages should start to be smaller, as we'll be able to use distribution versions of ZF2 going forward instead of git clones.

    Additionally, the following features were added:

    • zfcampus/zf-content-validation#8 adds the ability to provide HTTP method-specific input filters. This feature is not yet integrated into the Apigility Admin UI, but can be configured manually. To do so, add method/input filter service name pairs for the given controller service name; if no method-specific input filter exists, zf-content-validation will fallback to the input_filter key, if defined. As an example:

      'zf-content-validation' => array( 'Example\V1\Rest\Status\Controller' => array( // This is the fallback input filter, and the one the UI // can define and manipulate: 'input_filter' => 'Example\V1\Rest\Status\Validator', // This one will be used on POST requests only: 'POST' => 'Example\V1\Rest\Status\NewStatusValidator', ), ),

    • zfcampus/zf-mvc-auth#20 provides a patch that injects the MvcEvent with a new key, ZF\MvcAuth\Identity. You can pull the discovered identity from this event parameter now. Additionally, in REST resources, calling $this->getIdentity() will retrieve the identity.

    • zfcampus/zf-apigility-admin#124 and zfcampus/zf-apigility-admin#129 provide initial input filters for all Apigility Admin API services, as well as UI integration for reporting errors. All validation errors are caught and reported in a single dialog within the form that raises them.

    • The 'edit settings' screen for REST services now allows editing the entity class and collection class names.

    • The 'API Overview' page now links services to their overviews. The service description is displayed beneath each service; if not yet defined, a link to the 'edit documentation' tab for the service is provided.

    • A new modal will be displayed to users of the Apigility Admin UI if the API detects that the filesystem is not writable. The modal details what changes need to be made in order for the UI and API to work correctly.

    • zfcampus/zf-oauth2#30 splits out initialization of the oauth2-server-php server from the zf-oauth2 controller, allowing the ability to replace it, write a delegator for it, etc.

    Breaking Changes

    • zfcampus/zf-content-validation#10 changes the key used by the InputFilterAbstractServiceFactory from input_filters to input_filter_specs. This is due to the fact that ZF 2.3.0 introduces an InputFilterManager, which is already consuming the key input_filters. Wrapped in this change is the fact that the InputFilterAbstractServiceFactory is now registered as an abstract service factory with the InputFilterManager, instead of with the application service manager instance.

      For those updating their Apigility libraries to 1.0.0beta1, edit your module.config.php files to rename the input_filters key to input_filter_specs.

    • The zf-configuration controller ZF\Configuration\Controller was moved into zf-apigility-admin. This URI for the service remains the same, but the controller itself has moved. (This change was done to consolidate all Admin API controllers in the same module, as well as to reduce the dependencies needed in the zf-configuration component.)

    Fixes

    • zfcampus/zf-apigility-admin#115 - Ensures that non-SQLite PDO OAuth2 adapters may be provided without error.

    • zfcampus/zf-apigility-admin#117 - Ensure that the route_match is passed to the API when saving an RPC service.

    • zfcampus/zf-apigility-admin#118 - Ensure that the Content Negotiation selector is passed to the API correctly when saving an RPC service.

    • zfcampus/zf-apigility-admin#120 - Remove duplicate call to initialize the ServerUrl helper.

    • zfcampus/zf-apigility-admin#122 and zfcampus/zf-apigility-admin#123 - Add checks for array keys before accessing them when building the documentation graph for a given service operation.

    • zfcampus/zf-apigility-admin#126 - Updates the admin to pass the X-UA-Compatible meta tag in order to provide Internet Explorer compatibility.

    • zfcampus/zf-apigility-admin#132 - Ensures that authorization data is fetched each time a new service is created, a service is updated, or a service is deleted, ensuring the table reflects the current list of available services and HTTP methods.

    • zfcampus/zf-apigility-admin#133 - Updates the 'angular-flash' functionality to anchor flash messages to the bottom of the window. Additionally, any error flash messages now have a 'close' button, requiring user intervention for dismissal.

    • Many fixes were made to the UI to improve performance, remove UI refresh errors, provide more consistent color schemes, ensure tabs stay focussed between state transitions, etc.

    • The Apigility Admin API was updated to break the authentication service into more granular sub-services, one for each type of authentication supported. This simplifies validation, and allows for future expansion.

    • Work was done to ensure opcode cache detection is as solid as possible. We now properly distinguish between APC and APCu, allowing the latter to be enabled when using the Admin API.

    • zf-apigility-documentation was not correctly aggregating RPC documentation; this has been fixed.

    • We reviewed the various events triggered to ensure that they were happening in the correct order, which we defined as:

      • Authentication
      • HTTP method negotiation (is the method called allowed for the service?)
      • Authorization (is the discovered identity allowed to perform the requested action?)
      • Content Negotiation (determine incoming Content-Type and marshal data from request body; determine if Accept and/or Content-Type are valid for the request)
      • Content Validation

      Several event listener priorities were updated to fit the above requirements. A new listener, ZF\Rest\Listener\OptionsListener, was introduced to handle HTTP method negotiation for REST services, and is registered at the same priority as the RPC OptionsListener (which previously existed).

    • zf-configuration was updated to never write configuration using short-array notation; this was done to ensure compatibility of generated configuration with PHP 5.3 (as developers may use the admin API via 5.4, but deploy to 5.3).

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-1.0.0beta1.tgz(18.21 MB)
    zf-apigility-skeleton-1.0.0beta1.zip(21.65 MB)
  • 0.9.1(Mar 1, 2014)

    Fixes two critical issues in authentication/authorization reported against 0.9.0:

    • zfcampus/zfoauth2#27 reported an inability to save OAuth2 adapter details from the Apigility admin UI. These are now corrected.
    • A report on the apigility-users mailing list indicated that authorizations performed against REST entities were not working correctly. This was due to an incomplete change from "resource" to "entity" (as noted in the 0.9.0 release notes); the situation is now corrected.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-0.9.1.tgz(110.28 MB)
    zf-apigility-skeleton-0.9.1.zip(115.46 MB)
  • 0.9.0(Feb 28, 2014)

    Adds ability to provide API documentation, completing planned features for the 1.0 stable release.

    • Changes minimum supported PHP version to 5.3.23, in line with the upcoming ZF 2.3.0. We still recommend 5.4.8 for serving the admin user interface.

    • New modules, zf-apigility-documentation and zf-apigility-documentation-swagger, providing documentation visualizations of APIs created with Apigility. The base module provides both JSON and HTML visualizations via the URI /apigility/documentation, based on the Accept header value present. zf-apigility-documentation-swagger provides an additional JSON visualization for the mediatype application/vnd.swagger+json, for seeding a Swagger UI installation; additionally, it provides the Swagger UI via /apigility/swagger.

      zf-apigility-documentation is enabled by default in zf-apigility-skeleton; zf-apigility-documentation-swagger is an opt-in module.

    • The /admin and /welcome routes are now removed! The admin UI now uses /apigility/ui, and the welcome screen uses /apigility/welcome. New routes for documentation are also available, as detailed above.

    • A new module was created for Apigility-specific interfaces, zf-apigility-provider. The primary use case is for composition in modules that may or may not be consumed by Apigility (e.g., a general-purpose module that could be composed into many projects). The only interface currently is ZF\Apigility\Provider\ApigilityProviderInterface, which replaces Zend\Apigility\ApigilityModuleInterface (and thus prevents the necessity of installing all Apigility modules just to implement the interface!).

    • A new module was introduced for handling development mode, zf-development-mode; this is a fork of NFDevelopmentMode, which was based off the equivalent functionality in zf-apigility-skeleton's Application module. We removed the functionality from the skeleton, and added a dependency on the new module.

    • zf-apigility-skeleton's layout was updated to match that of the admin UI.

    • zf-apigility-admin received numerous updates:

      • Ability to add documentation of services, fields, and operations.
      • Ability to use MongoDB when configuring an OAuth2 authentication adapter.
      • Ability to inspect, add, configure, and delete zf-content-negotiation selectors.
      • Links to HTML documentation of APIs managed by the Apigility instance (more on this below).
      • Ability to create and manipulate filter chains for each field in a service.
      • (Limited) detection of whether or not an opcode cache is enabled; if detected, a modal dialog will be presented to the end-user detailing how to disable it.
      • Completely overhauled and refactored admin UI application to ease maintenance and feature additions. The admin UI now uses Bower for managing UI asset dependencies, and Grunt for building the UI distribution. We have dropped ng-route for the angular-ui ui-router, providing us with more flexibility in UI implementation and layout. All services, controllers, and directives have been moved into their own files.
      • Countless UI/UX improvements.
    • zf-apigility-welcome has been updated to use the Apigility "Rocket ElePHPant" logo for the splash screen, and to provide buttons to the HTML and Swagger documentation, if the appropriate modules are available.

    • zf-rest and zf-rpc now each store a service_name key in the configuration for each service. While efforts have been made to ensure existing configuration still works, we recommend adding this key to each service. The value should be the short name representation for the service, usually the name you provided when creating the service.

    • All repositories have been updated to make a clean distinction between the terms "Entity", "Collection", and "Resource". An "Entity" is anything addressable via a URI containing a unique identifier. A "Collection" is any URI that returns a set of entities. A "Resource" refers to a URI that may return collections and/or entities. As such, we have several BC breaks:

      • The event renderResource is now renderEntity.
      • The event renderCollection.resource is now renderCollection.entity.
      • ZF\Hal\Resource was renamed to ZF\Hal\Entity.
      • The subkey resource in the zf-mvc-auth configuration is now entity.
      • The subkey resource_http_methods in zf-rest is now entity_http_methods.
      • The subkey resource_class in zf-rest is now entity_class.
      • The subkey resource_identifier_name in zf-rest is now entity_identifier_name. (This change only affects those who have been using latest master, but have not updated since late-January 2014.)
      • The subkey identifier_name in zf-apigility db-connected configuration is now entity_identifier_name;
    • zf-hal now properly differentiates between the identifier used in the route definition, and the identifier used for the entity; this allows you to use one value on the uri -- e.g., status_id -- and another in your entity class -- e.g., id. zf-hal will fallback to the route_identifier_name if no entity_identifier_name is present.

    • zf-apigility, when detecting an input filter is present, will pull values from the input filter, and not use any other values even if provided in the request. This prevents SQL errors due to unknown columns.

      Additionally, zf-apigility's assets were updated, and a Grunt + Bower toolchain provided for keeping them up-to-date.

    • zf-rest, when detecting an input filter is present for the current request, will inject it into the ResourceEvent, allowing developers to retrieve it via $this->getEvent()->getInputFilter().

      Additionally, support for patchList was added to the AbstractResourceListener.

    • zf-api-problem was updated to match Problem API draft 5. This has changed the internal structure and JSON representation of problem results. If you were manipulating ApiProblem objects directly previously, you may need to alter your code.

    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-0.9.0.tgz(110.29 MB)
    zf-apigility-skeleton-0.9.0.zip(115.47 MB)
  • 0.8.0(Dec 20, 2013)

    Adds content validation support.

    • Ups minimum supported PHP version to 5.4.8.
    • New module, zf-content-validation, which allows associating ZF2 input filters with named controller services, as well as creation of named input filters via a ZF2 abstract service factory. For requests with content, if the matched controller has an associated input filter, the data is passed to the input filter, and an error is returned on validation failure.
      • 422 responses are returned when validation fails.
      • 400 responses are returned when the content contains unrecognized data.
    • Admin UI now adds an "Inputs" tab to each service, allowing the user to create and edit inputs for the service, as well as associate validators.
    • Hydrators are now specified via a dropdown, populated from a list of known hydrator services in the application.
      • The ArraySerializable hydrator is now specified as the default hydrator for REST entity objects.
    • The AbstractResourceListener now correctly pulls any whitelisted query string variables and passes them to the fetchAll() method.
    • You may now specify the default version to use when no version is specified (previously, hard-coded to use version 1 as the default version).
    • The Admin API will now report an error if you attempt to create a new API and a matching module name already exists.
    • All Apigility modules now use "next significant release" notation in their composer.json files to ensure the latest stable version or development version will be selected (vs only the latest development version).
    • All Apigility modules have been updated to ensure they are compatible with Cross Origin Resource Sharing (CORS) requests.
    • Tables used with DB-Connected REST resources can now contain underscores in their names.
    • Content negotiation now detects JSON decoding errors and raises an exception when detected.
    • Composed ZF\Hal\Link\Link properties in objects rendered as HAl will be rendered as relational links.
    • The collection name of a HAL collection can now be specified in HAL metadata configuration.
    • OAuth2 support has been improved to allow better integration between ZF2 and oauth2-server-php request objects, and to allow the password grant type.
    Source code(tar.gz)
    Source code(zip)
    zf-apigility-skeleton-0.8.0.tgz(93.29 MB)
    zf-apigility-skeleton-0.8.0.zip(98.83 MB)
  • 0.7.0(Nov 15, 2013)

Owner
Zend Framework Campus
Zend Framework Campus