Apigility Version 0.9.0
Pre-releaseAdds 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 mediatypeapplication/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 nowrenderEntity
. - The event
renderCollection.resource
is nowrenderCollection.entity
. ZF\Hal\Resource
was renamed toZF\Hal\Entity
.- The subkey
resource
in the zf-mvc-auth configuration is nowentity
. - The subkey
resource_http_methods
in zf-rest is now
entity_http_methods
. - The subkey
resource_class
in zf-rest is nowentity_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-apigilitydb-connected
configuration
is nowentity_identifier_name
;
- The event
-
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 theroute_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 theResourceEvent
, 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 manipulatingApiProblem
objects directly previously,
you may need to alter your code.