Download the PHP package zfcampus/zf-apigility-admin without Composer

On this page you can find all versions of the php package zfcampus/zf-apigility-admin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of zfcampus/zf-apigility-admin

Informations about the package zf-apigility-admin

Apigility Admin

Repository abandoned 2019-12-31

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

Build Status

Introduction

The zf-apigility-admin module delivers the backend management API and frontend Admin UI used to manage APIs in Apigility.

NOTE

DO NOT enable this module in production systems.

Requirements

Please see the composer.json file.

Installation

Run the following composer command:

And then run composer install to ensure the module is installed.

Finally, add the module name to your project's config/application.config.php under the modules key:

Typically, this module should be used along with zf-development-mode in order to conditionally enable the module in your application. When doing so, you will add the module to your project's config/development.config.php.dist file instead of the config/application.config.php file, and enable it via php public/index.php development enable.

Upgrading

We strive to make upgrading as simple as a composer update; however, from time to time, there may be other steps involved. This section documents those.

Initial upgrade to 1.5

If you are upgrading to version 1.5 or higher from a pre-1.5 version, there are a few changes to be aware of.

First, version 1.5 drops the requirement for rwoverdijk/assetmanager. However, in order to use the admin UI, you will need some way to access the public assets provided by the UI and zf-apigility modules. You have three options:

  1. Install rwoverdijk/assetmanager: composer require rwoverdijk/assetmanager. Be aware, however, that as of the time of the 1.5.0 release, this module is not compatible with v3 releases of zend-mvc. If you are looking for a quick upgrade, and do not care what versions of Zend Framework components you install, this is the easiest path.

  2. Install zf-asset-manager. This is a Composer plugin, and operates when installing or uninstalling a package. If you add this, you will need to follow these steps:

    • composer require --dev zfcampus/zf-asset-manager
    • rm -Rf ./vendor
    • composer install

    • The additional steps are necessary in order for the plugin to pick up on the assets from the other components.

  3. Manually copy or symlink in the assets required to your public directory. As examples:

    • ln -s vendor/zfcampus/zf-apigility/asset/zf-apigility public/zf-apigility
    • ln -s vendor/zfcampus/zf-apigility-admin-ui/dist/apigility-ui public/apigility-ui

Each of the three will accomplish the goal of making the assets publicly available via your application's web server.

Upgrading to v3 Zend Framework components from 1.5

After upgrading to version 1.5 of this module, you can then upgrade your application to take advantage of Zend Framework v3 components. The easiest way to do that is to use the provided script:

This script will update your Composer requirements and constraints, update your modules list to list ZF components and remove unneeded/obsolete components, and then re-install all dependencies.

If you do not wish to use the script, or the script fails, you may manually update your application using the following steps:

Development Mode

Prior to 1.5 and running the upgrade script or following the upgrade instructions from above, Apigility used zf-development-mode v2 releases, which relied on the Console <-> MVC integration present by default in zend-mvc v2 releases.

zf-development-mode v3 operates differently, however, and instead ships as a Composer vendor binary, with no additional requirements. Invocation is now:

and

You can also query for status:

Configuration

Since this particular module is responsible for providing APIs and the Apigility Admin UI, it has a significant amount of configuration that it requires in order to function in a development environment. Since it is highly unlikely that developers would need to modify the system-level configuration, it is omitted in this README, but can be found within the repository.

Additionally, the module defines the following module-specific configuration, under the top-level key zf-apigility-admin:

Key: path_spec

By default, zf-apigility-admin will create new Apigility modules using PSR-0 directory structure. You can switch to PSR-4 using the zf-apigility-admin.path_spec configuration, which accepts one of the following values:

Routes

This module exposes HTTP accessible API endpoints and static assets.

API Endpoints

All routes are prefixed with /apigility by default.

api/apigility-version

Returns the current Apigility version if it can be discovered, and the string @dev otherwise. The payload is in the version key:

api/config

This endpoint is for examining the application configuration, and providing overrides of individual values in it. All overrides are written to a single file, config/autoload/development.php; you can override that location in your configuration via the zf-configuration.config-file key.

api/config/module?module={module name}

This operates exactly like the api/config endpoint, but expects a known module name. When provided, it allows you to introspect and manipulate the configuration file for that module.

api/authentication

This REST endpoint is for creating, updating, and deleting the authentication configuration for your application. It uses the authentication resource.

api/authentication[/:authentication_adapter] (API V2)

This REST endpoint is for fetching and updating the authentication adapters to be used in Apigility. It uses the authentication resource ver. 2.

This endpoint is only available for API version 2. You need to pass the following mediatype in the Appect header:

api/module/:name/authentication?version=:version (API V2)

This REST endpoint is for fetching and updating the authentication mapping for a specific API (module) and version, if specified.

This endpoint is only available for API version 2. You need to pass the following mediatype in the Appect header:

api/module/:name/authorization?version=:version

This REST endpoint is for fetching and updating the authorization configuration for your application. It uses the authorization resource.

api/db-adapter[/:adapter_name]

This REST endpoint is for creating, updating, and deleting named Zend\Db adapters; it uses the db-adapter resource.

api/module.enable

This endpoint will Apigility-enable (Apigilify?) an existing module.

The request payload should hav ethe following structure:

api/validators

This endpoint provides a sorted list of all registered validator plugins; the use case is for building a drop-down of available plugins when creating an input filter for a service. Any validator present in the ZF2 ValidatorPluginManager service will be represented.

The response payload for a successful request has the following format:

api/versioning

This endpoint is for adding a new version to an existing API. If no version is passed in the payload, the version number is simply incremented.

The request payload should have the following structure:

On success, the service returns the followings structure:

api/module[/:name]

This is the canonical endpoint for Module resources.

When creating a new API module, use the following request payload:

api/module/:name/rpc[/:controller_service_name]

This is the canonical endpoint for RPC resources.

The minimal request payload necessary will have the following structure:

api/module/:name/rpc/:controller_service_name/inputfilter[/:input_filter_name]

This service is for creating, updating, and deleting named input filters associated with a given RPC service.

api/module/:name/rest[/:controller_service_name]

This is the canonical endpoint for REST resources.

Can be used for any type of REST resource, including DB-Connected.

DB-Connected resources expect the following additional properties (and will return them as well):

The minimum structure for creating a new REST service will appear as follows:

api/package

This endpoint is for building a deploy package for APIs.

The request payload for POST should have the following structure:

On success, the service returns the followings structure:

The fields of this response can be used in the GET method to download the package file. Basically, the token is a temporary file name stored in the system temporary folder (/tmp in GNU/Linux).

The request payload for GET should have the following structure:

On success, the service returns the file as application/octet-stream content type.

API Models

The following is a list of various models either returned via the API endpoints listed above, or expected for the request bodies.

authentication

HTTP Basic authentication:

HTTP Digest authentication:

OAuth2 authentication:

authentication2

HTTP Basic authentication:

HTTP Digest authentication:

OAuth2 authentication (with PDO):

OAuth2 authentication (with MongoDB):

authorization

REST services have an entry for each of their entity and collection instances. RPC services have an entry per action name that is exposed (this will typically only be one). Each service has a list of HTTP methods, with a flag. A false value indicates that no authorization is required; a true value indicates that authorization is required.

Note: If the deny_by_default flag is set in the application, then the meaning of the flags is reversed; true then means the method is public, false means it requires authentication.

db-adapter

Additionally, any other properties used to create the Zend\Db\Adapter\Adapter instance may be composed: e.g., "username", "password", etc.

inputfilter

An input filter may contain any number of inputs, and the format follows that used by Zend\InputFilter\Factory as described in the [Zend Framework 2 input filter documentation] (http://framework.zend.com/manual/2.3/en/modules/zend.input-filter.intro.html).

Currently, we do not allow nesting input filters.

module

Additionally, the module resource composes relational links for RPC and REST resources; these use the relations "rpc" and "rest", respectively.

rpc

rest

ZF2 Events

Listeners

ZF\Apigility\Admin\Module

This listener is attached to MvcEvent::EVENT_RENDER at priority 100. It is responsible for conditionally attaching a listener depending on if the controller service result is that of an entity or that of a collection. If either is detected, the listener is attached to the ZF\Hal\Plugin\Hal events renderEntity and renderCollection.entity, which ensures they will be dispatched when the HAL plugin has an opportunity to start rendering.

ZF2 Services

Models

Many of the model services provided by zf-apigility-admin either deal with the generation and modification of PHP code, or the generation and modification of PHP based configuration files.

All versions of zf-apigility-admin with dependencies

PHP Build Version
Package Version
Requires php Version ^5.6 || ^7.0
zendframework/zend-code Version ^2.6.3 || ^3.2
zendframework/zend-eventmanager Version ^2.6.3 || ^3.0.1
zendframework/zend-filter Version ^2.8
zendframework/zend-http Version ^2.8
zendframework/zend-hydrator Version ^1.1 || ^2.4 || ^3.0
zendframework/zend-inputfilter Version ^2.8.1
zendframework/zend-modulemanager Version ^2.8.2
zendframework/zend-mvc Version ^2.7.15 || ^3.1.1
zendframework/zend-servicemanager Version ^2.7.10 || ^3.3.2
zendframework/zend-stdlib Version ^2.7.7 || ^3.2
zendframework/zend-validator Version ^2.10.2
zendframework/zend-view Version ^2.10
zfcampus/zf-apigility Version ^1.4
zfcampus/zf-apigility-admin-ui Version ^1.3.9
zfcampus/zf-apigility-provider Version ^1.3
zfcampus/zf-api-problem Version ^1.3
zfcampus/zf-configuration Version 1.3.3
zfcampus/zf-content-negotiation Version ^1.4
zfcampus/zf-content-validation Version ^1.4
zfcampus/zf-hal Version ^1.5
zfcampus/zf-oauth2 Version ^1.5
zfcampus/zf-mvc-auth Version ^1.5
zfcampus/zf-rest Version ^1.4
zfcampus/zf-rpc Version ^1.4
zfcampus/zf-versioning Version ^1.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package zfcampus/zf-apigility-admin contains the following files

Loading the files please wait ....