Download the PHP package solvire/php-hypermedia-api without Composer

PHP Hypermedia API Layer for HATEOAS HTTP or REST Services

Repo: php-hypermedia-api

NO REST 4 U!

Let's just say it. Your API is probably not RESTful. I don't even like using the term anymore.

Sadly I do not maintain this anymore. The PHP community did not seem to feel the need for such structure.

Installation

composer require solvire/php-hypermedia-api

Compatibility

Runs on:

• php 5.5+
• php 7
• HHVM

Frameworks

• Laravel

History

This work originally started trying to bring the LeadFerret front-end user API into compliance. It was something I started a few years ago, but was never given the chance to finish. Late nights and coffee pushed it through.

Philosophy

Why?

"Knowing the questions to ask is sometimes more important than knowing the answer." - Smart A. Dude

When you land on a random webpage the authors care enough to provide you a way to navigate the server. Most APIs will only return exactly what you are asking for. You have to read the documentation to know where to go next and what that record actually means.

Hypermedia API

The / root of the application should provide enough information that a machine may transverse the server on it's own.

This library intends to wrap an agnostic framework and provide utilities to produce hypermedia context more easily. This context is meaning behind the returned data.

For REST to be valid it needs to provide context in the form of hypermedia. Again see Roy T. Fielding on the topic.

HATEOAS - Hypermedia as the Engine of Application State

Architecture

JSON-Schema

Taking a queue from google developers discoverability service, we opted for using the JSON Schema definition structure. Specifically JSON Schema draft 04.

There are obvious benefits with having a schema in place. Validation, client generation, etc.

In order for JSON Schema to work properly the types of responses are strongly defined. There is no guessing.

Some of the features were loosely modeled on the Django Rest Framework (DRF). Primarily how they treat their views which we call renderers.

Schemas

When creating a web service the default schema return from the root level of the resources. This is part of a somewhat separate JSON-Schema controller. It shows some of the application level items.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "basePath": "/public/api",
  "baseUrl": "https://api.yourdomain.com",
  "description": "API Cool End-User API",
  "documentationUrl": "http://docs.domain.apiary.io/#",
  "id": "appname:v1",
  "name": "appname",
  "version": "v1.0"
}

Class Structure

<img src="docs/laravel_hypermedia.png" alt="PHP Hypermedia API" width="800" />

Representation Controllers

This object will be the authority to respond back to the control with all data and context related to the resource. Attached to it are the renderers which can present and handle interactions with the data.

Renderers

This is the gateway in and out of the database. It takes the data in and moves it through the serializer into the DB. Also in reverse. Some can also just parse an array for static content. They should be output agnostic. The serializers are attached.

Serializers

Define your resource structure here. Each field has an object with very specific types.

Data Fields

There is an object for each one of your favorite data types. Below is the list.

• BooleanField
• CharField
• DataField
• DataFieldCollection
• DateField
• DateTimeField
• DoubleField
• EmailField
• FileField
• FloatField
• IPAddressField
• ImageField
• IntegerField
• ListField
• PointField
• ReadOnlyField
• RegexField
• SplitPointField
• TimeField
• URLField
• UUIDField
• PhoneField
• GenderField (normalized)
• TransformerField (fractal)
• SerializerField (recursive)

Data Field Condition Attributes

For each data field there are a set of attributes which will affect the functionality of your serializer. Most of the attribute refer to transformations that might occur, while some are validators or filters.

Read Only

readOnly

A field that is marked as 'readOnly'=>true may not be written to. The serializer should ignore this field in determining data writes.

Examples of this are date fields or account status fields.

Default: false

Write Only

writeOnly

A field marked as 'writeOnly'=>true will not be displayed to the end user. They are written to and may have filters or validators applied to them.

Examples are passwords or point increment

Default: false

Required Field

required

If a field is marked with 'required'=>true causes the system to throw an error if the field is not present during the update. Setting this to false is unnecessary since that is the default setting.

Default: false

Allow Null Values

allowNull

If the field is marked with 'allowNull'=>true the serializer will allow you to pass a null value with the field. The recording agent should also respect this request and set the data field to null as well.

Default: false

Allow Empty Strings

allowEmpty

If the field is marked with 'allowEmpty'=>true the serializer will allow you to pass an empty string ''. The recording agent should also respect this request and set the data field to blank as well. Note that null and empty strings are not the same. They should be treated differently.

Default: false

Default Value

defaultValue

Many times you may want to set a default value so that if the data isn't in the db or passed in that it is set already. 'defaultValue'=>'something'

Default: null

Column Name - Alias

One of the biggest problems with an API response value is setting the keys and translating back and forth. Setting a column name will help readability and usability. 'columnName'=>'mapped_column'. For instance your users doesn't need to know the primary column is CompanyNameID. Just 'id' will be fine.

Examples: Primary keys, sensitive names, ugly names

Default: null - uses your DB column name

Validators

This is not implemented yet, but you can assume that we will be allowing the ability to pass in chains of validators. We may standardize but that hasn't happened yet. Suggestions are welcome.

Output Specific Attributes

Styling

This is not implemented yet but you may pass back output related styling.

Help Text

For form fields and UI components it may be helpful to deploy information about it for the human interface. Not implemented yet.

Serializer Example

Here is an example of a serializer for a company record. It extends the LaravelModelSerializer which can interface with Laravel models explicitly. At some point we will integrate with symfony but not at this time.

Here we have an example of a health check serializer. Since this is just a heartbeat response we don't really need to interface with the database. It doesn't need data binding. For this case we just extended the ArraySerializer. Basically only output although we might be able to find some input use cases for it.

The server response will look like this. It should format the fields into their proper data types. More flexibility will be added for the various fields in the future. Things such as setting timezones and adding translations.

I've included a class here with some examples of two data field types: TransformerField and SerializerField. As you expect these perform complex nested serializations. Below this class is an example of a sample output.

The serializer field is basically a tested data field for bringing in already defined serializers.

The transformer can transform your data in any format you need. Literally. I had a unique case I had to combine a lot of fields to create the data as it was so I passed the model in the closure.

And the output: