Download the PHP package proklung/symfony-guzzle-bundle without Composer

Бандл для получения сконфигурирированных экземпляров Guzzle. Поддержка middlewares и т.д.

Форк пакета, доработано под личные нужды (добавлен адаптер для кэширования в Битриксе, и т.п).

Установка

1) composer require proklung/symfony-guzzle-bundle

Использование

Конфигурация

You may also enable the included logger, in order log outcoming requests:

Autowiring

If you rely on Symfony autowiring, you can choose to alias a specific service to the GuzzleHttp\ClientInterface interface and GuzzlHttp\Client class.

Then, your github_api client will be automatically injected into your controller or service:

Creating a service for your client

There are two ways for creating a service for your client:

• Using the semantic configuration (Beginners)
• Registering your own service (Advanced users)

Creating a client using semantic configuration

Simply write the following code:

The previous code will create a new service, called csa_guzzle.client.github_api, that you can use in your controller, or that you can inject in another service:

You may want to mark the service as lazy.

If you override your client's class, you can also set the class for your client:

Of course, you need to make sure that your client class' constructor has exactly the same signature as Guzzle's Client class.

Registering your own service

To have a client supported by the bundle, simply tag it as such:

YAML:

Creating new middleware

Creating a new Guzzle middleware is as easy as creating a symfony service and using the csa_guzzle.middleware tag, giving it an alias and (optionally) a priority:

You can also define middleware as a class with the __invoke method like this:

The service definition for such a class is then:

Middleware are automatically used by all your clients, if you are using the semantic configuration. However, if you wish to, you can limit a client to a list of specific middleware:

You can also disable specific middleware, by prefixing the middleware name with a ! character:

You can either whitelist or blacklist middleware. Using both whitelisting and blacklisting will trigger an exception.

When registering your own clients with the bundle, you can explicitly list all enabled middleware. The middleware attribute takes a space-delimited list of middleware names. In that case only the specified middleware will be registered for that client:

YAML:

BitrixCacheAdapter

Определяется сервис кэширования. Например, так:

И в конфигурации бандла указывается:

Available middleware

Currently, five middleware are available:

• the logger middleware
• the cache middleware
• the mock middleware

The logger middleware

The logger middleware's objective is to provide a simple tool for logging Guzzle requests.

Enabling request logging, you simply need to enable it in Symfony's configuration:

Like the debug middleware, there's also a shorthand syntax to enable it:

Using the advanced configuration, you may also configure your own logger, as long as it implements the PSR-3 LoggerInterface:

You can configure the log format using the syntax described in guzzlehttp/guzzle's documentation. You may also use of the three levels described in the formatter: clf (Apache log format), debug, or short:

You could also change the level of logging, for dev, you likely want debug, for prod, you likely want error. You'll find more log levels in the LogLevel of php-fig.

The cache middleware

The cache middleware's objective is to provide a very simple cache, in order to cache Guzzle responses.

Even though only a doctrine/cache adapter is provided (Prokl\GuzzleBundle\GuzzleHttp\Cache\DoctrineAdapter), the middleware is agnostic. If you wish to use your own cache implementation with the cache middleware, you simply need to implement Prokl\GuzzleBundle\GuzzleHttp\Cache\StorageAdapterInterface, and you're set!

This middleware can be configured with the following configuration:

To use the doctrine cache adapter, you need to use the Prokl\GuzzleBundle\GuzzleHttp\Cache\DoctrineAdapter class, in which you should inject your doctrine cache service. For example, using doctrine/cache's FilesystemCache:

The mock middleware

When running tests, you often want to disable real HTTP requests to your (or an external) API. The mock middleware can record those requests to replay them in tests.

The mock middleware can work in two modes:

• record, which saves your HTTP requests inside a directory in your filesystem
• replay, which uses your saved HTTP requests from the same directory

Of course, this middleware should only be used in the test environment (or dev, if you don't have access to the remote server):

The generated files can then be committed in the VCS.

To use them, simply change the mode to replay:

A few customizations can be done with the mock middleware. You can indeed blacklist:

• Request headers, so they are not used for generating the mock's filename.
• Response headers, so they are not saved in the mock file.

For this, you can simply configure your client as follows:

Configuration reference

To log request/response body you can use {req_body} and {res_body} respectively in format setting.

Full list of logs variables with description:

Reference Guzzle Log Plugin Docs

Прочее

1) Альтернативный Guzzle Logger - для использования вне рамок бандла - Prokl\GuzzleBundle\Middlewares\Raw\GuzzleLogger