Download the PHP package chaplean/api-client-bundle without Composer

Chaplean Api Client Bundle

Library to help defining client for rest apis.

Table of content

• Installation
• Creating bundles based on api-client-bundle
  • Configuration
  • Creating an Api class
  • Defining an Api
• Using a bundle based on api-client-bundle
• Additional Features
• Commands
• Versioning
• Contributing
• Hacking
• License

Installation

This bundle requires at least Symfony 3.0.

You can use composer to install api-client-bundle:

Then add to your AppKernel.php:

Creating bundles based on api-client-bundle

This section describes how you can create your own api bundle based on this project. If you want examples see our own api bundles on packagist or github.

Configuration

First you will need to configure guzzlehttp that we use under the hood to perform the actual http requests. See the bundle documentation or the library documentation for the full range of options.

config.yml:

You will also probably want to create some custom parameters.

parameters.yml:

As you inject guzzle in your Api class you can have different configuration per Api. See next section.

Creating an Api class

To use api-client-bundle you have to create a class extending AbstractApi. You can create any number of classes extending AbstractApi and have all of them using different configurations via dependency injection.

And we're done! We could repeat this process to create another Api with completely different configurations.

Defining an Api

Let's focus on the function you have to fill in and what we can do in it. The role of this function is to define your Api using the api-client-bundle's api:

Parameter options

List of options for the parameters

Using a bundle based on api-client-bundle

This section describes how to use a bundle based api-client-bundle.

As shown in the previous section the api defines a list of routes and the parameters they accept. To call a route you need to provide them.

For an api with the following definition:

We can call the getUser() method, provide the parameters and run the request:

Here we called bindUrlParameters() to provide values for the parameters defined with urlParameters(). Similarly, for parameters defined with headers(), queryParameters() and requestParameters() there is a bindHeaders(), bindQueryParameters() and bindRequestParameters().

You have to call these functions with a key => value array. There is a validation pass during exec() before running the request making sure the values you provided match the definitions in the api.

Finally, exec() returns a ResponseInterface. Several implementations of this interface exist:

• InvalidParameterResponse: The parameters provided didn't weren't valid;
• RequestFailedResponse: Request performed but failed (network issue or non 2xx status code);
• PlainResponse: Request suceeded and route was either defined with expectsPlain() or it wasn't specified;
• JsonResponse: Request suceeded and route was defined with expectsJson();
• XmlResponse: Request suceeded and route was defined with expectsXml();

Among the functions in ResponseInterface here are some usefull ones and how you could use them:

Additional Features

This bunde expose some configuration if you want to enable extra features. You can enable database and / or email logging of requests. To use the database or email loggers you will have to setup respectively doctrine or swiftmailer in your project. The default configuraton is:

config.yml:

You can override the default email content by overriding the translation keys or even the email body twig template. The translation keys are under chaplean_api_client.email.request_executed_notification and the template is Resources/views/Email/request_executed_notification.txt.twig.

Commands

To clean the logs from the Database, you may use the command chaplean:api-logs:clean [minimumDate]. It will remove old logs, only keeping those more recent than the given minimumDate date. By default, this argument date is now -1 month. It should be formatted as a PHP's DateTime string.

This command makes irreversible changes in your database, so we strongly recommend you to back up the logs before executing it.

Versioning

api-client-bundle follows semantic versioning. In short the scheme is MAJOR.MINOR.PATCH where

1. MAJOR is bumped when there is a breaking change,
2. MINOR is bumped when a new feature is added in a backward-compatible way,
3. PATCH is bumped when a bug is fixed in a backward-compatible way.

Versions bellow 1.0.0 are considered experimental and breaking changes may occur at any time.

Contributing

Contributions are welcomed! There are many ways to contribute, and we appreciate all of them. Here are some of the major ones:

• Bug Reports: While we strive for quality software, bugs can happen and we can't fix issues we're not aware of. So please report even if you're not sure about it or just want to ask a question. If anything the issue might indicate that the documentation can still be improved!
• Feature Request: You have a use case not covered by the current api? Want to suggest a change or add something? We'd be glad to read about it and start a discussion to try to find the best possible solution.
• Pull Request: Want to contribute code or documentation? We'd love that! If you need help to get started, GitHub as documentation on pull requests. We use the "fork and pull model" were contributors push changes to their personnal fork and then create pull requests to the main repository. Please make your pull requests against the master branch.

As a reminder, all contributors are expected to follow our Code of Conduct.

Hacking

You might find the following commands usefull when hacking on this project:

License

api-client-bundle is distributed under the terms of the MIT license.

See LICENSE for details.