bradfeehan / guzzle-modular-service-descriptions
A better ServiceDescriptionLoader for Guzzle 3.x
Installs: 110 431
Dependents: 2
Suggesters: 0
Security: 0
Stars: 2
Watchers: 3
Forks: 3
Open Issues: 0
Requires
- php: >=5.3
- guzzle/guzzle: ~3.0
- symfony/yaml: ~2.3
Requires (Dev)
- mockery/mockery: 0.9.0
- phpunit/phpunit: ~3.7.0
This package is not auto-updated.
Last update: 2024-11-09 15:42:54 UTC
README
A better ServiceDescriptionLoader for Guzzle 3.x
Features
Guzzle's service descriptions make it easy to describe APIs. A service description takes the form of a JSON object (or PHP associative array) that describes all the available operations and data models supported by the API. However, for large or poorly-designed APIs, the service description can quickly become hard to manage.
This project offers a replacement ServiceDescriptionLoader implementation, which allows for much more flexibility when writing service descriptions. It supports:
- Separating the service description arbitrarily into many files ("modular" service descriptions)
- Alternative formats (plain text and YAML)
Installation
To get this library in to an existing project, the best way is to use Composer.
-
Add
bradfeehan/guzzle-modular-service-descriptions
as a Composer dependency in your project'scomposer.json
file:{ "require": { "bradfeehan/guzzle-modular-service-descriptions": "~1.0" } }
-
If you haven't already, download and install Composer:
$ curl -sS https://getcomposer.org/installer | php
-
Install your Composer dependencies:
$ php composer.phar install
-
Set up Composer's autoloader:
require_once 'vendor/autoload.php';
Usage
In contrast to typical Guzzle service descriptions, a modular service description is implemented as a directory. The format of the directory is very flexible. The directory structure is reflected in the heirarchy of the service description data.
Format
A file in the root of a modular service description directory defines the key with the name of the file. The content of the file defines the value of that key. As an example, consider the following directory structure:
my_service_description/
├── name.txt
└── operations.json
The my_service_description
directory can be loaded as a modular
service description. The content inside name.txt
will be put into the
key name
at the top level of the service description. The content of
operations.json
will be the value for the operations
key in the
service description. (So, to be a valid service description,
operations.json
should contain a JSON object, defining all the
operations).
Nested directories
Another, more complex example:
complicated_service_description/
├── name.txt
└── operations/
├── ComplexOperation/
│ └── parameters.yml
└── ComplexOperation.json
Again, name.txt
will contain the value for the name
key. However,
this time, the operations
key is represented by a directory. The
files inside are converted to nested keys in the resulting service
description. So this example will result in the following
representation:
{ "name": "[content of name.txt]", "operations": { "ComplexOperation": { // The keys defined in ComplexOperation.json // will be inserted here // ... "parameters": "[parsed content of parameters.yml]" } } }
__index
files
Any files named __index.[ext]
define the contents of the directory the
file is in, rather than the name of the file. It's essentially an
"empty" name. This concept is similar to Python's __init__.py
, which
makes the directory the package, rather than the file.
Groups
Files can also be grouped without causing the contents to be nested.
This is useful for organising a large service description. For example,
if there are thousands of operations, you'd have to have that many
files in the operations
directory. Using groups, the operations can
be grouped logically inside the operations
directory.
A group is implemented as a directory ending with .group
. So you
could have Users.group
containing all the operations relating to
users, etc.
Note that this could cause problems if you wanted to have a key ending
with .group
. Please let me know by filing a GitHub issue if this
causes you any issues, and we can work out a way to compromise.
Loading the service description
To load a modular service description, load it using the included loader, and add it to the web service client instance:
use BradFeehan\GuzzleModularServiceDescriptions\ServiceDescriptionLoader; use Guzzle\Service\Client; // Create a client somehow $client = Client::factory(); // Instantiate the modular service description loader $loader = new ServiceDescriptionLoader(); // Point the loader at the modular service description directory $description = $loader->load('/path/to/service_description'); // Add the service description to the client $client->setDescription($description); // Done! $command = $client->getCommand('MyCommand'); // ...