0.9.0 Changelog

Laminas API Tools Version 0.9.0

Based on https://github.com/zfcampus/zf-apigility-skeleton/releases/tag/0.9.0 (commit 3be96cbc9f19342d4b64ad25f22bc23d012c3115 in this repo)

=======================

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 Laminas 2.3.0. We still recommend 5.4.8 for serving the admin user interface.

  • New modules, api-tools-documentation and api-tools-documentation-swagger, providing documentation visualizations of APIs created with Laminas API Tools. The base module provides both JSON and HTML visualizations via the URI /api-tools/documentation, based on the Accept header value present. api-tools-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 /api-tools/swagger.

    api-tools-documentation is enabled by default in api-tools-skeleton; api-tools-documentation-swagger is an opt-in module.

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

  • A new module was created for Laminas API Tools-specific interfaces, api-tools-documentation. The primary use case is for composition in modules that may or may not be consumed by Laminas API Tools (e.g., a general-purpose module that could be composed into many projects). The only interface currently is Laminas\ApiTools\Provider\ApiToolsProviderInterface, which replaces Laminas\ApiTools\ApiToolsModuleInterface (and thus prevents the necessity of installing all Laminas API Tools modules just to implement the interface!).

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

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

  • api-tools-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 api-tools-content-negotiation selectors.

    • Links to HTML documentation of APIs managed by the Laminas API Tools 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.

  • api-tools-welcome has been updated to use the Laminas API Tools "Rocket ElePHPant" logo for the splash screen, and to provide buttons to the HTML and Swagger documentation, if the appropriate modules are available.

  • api-tools-rest and api-tools-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.

    • Laminas\ApiTools\Hal\Resource was renamed to Laminas\ApiTools\Hal\Entity.

    • The subkey resource in the api-tools-mvc-auth configuration is now entity.

    • The subkey resource_http_methods in api-tools-rest is now entity_http_methods.

    • The subkey resource_class in api-tools-rest is now entity_class.

    • The subkey resource_identifier_name in api-tools-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 api-tools db-connected configuration is now entity_identifier_name;

  • api-tools-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. api-tools-hal will fallback to the route_identifier_name if no entity_identifier_name is present.

  • api-tools, 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, api-tools's assets were updated, and a Grunt + Bower toolchain provided for keeping them up-to-date.

  • api-tools-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.

  • api-tools-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.