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

On this page you can find all versions of the php package mardraze/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?

Informations about the package zf-apigility-admin

Apigility 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.

Configuration

There is no custom user level configuration for this module.

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.

Routes

This module exposes HTTP accessible API endpoints and static assets.

API Endpoints

All routes are prefixed with /apigility by default.

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
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 mardraze/zf-apigility-admin contains the following files

Loading the files please wait ....