carsdotcom/php-request-class

Structure the logic around Guzzle API requests into object-oriented classes

v1.3.0 2024-10-30 19:16 UTC

Requires

• php: ^8.1
• ext-simplexml: *
• carsdotcom/laravel-json-schema: ^v1.0 || v2.0 || v2.1
• guzzlehttp/guzzle: ^7.5
• laravel/framework: ^9.19 || ^10.0 || ^11.0

Requires (Dev)

• fakerphp/faker: ^1.9.1
• nunomaduro/collision: ^6.1|7.*|8.*
• orchestra/testbench: 7.*|8.*|9.*
• phpstan/phpstan: ^1.8
• phpunit/phpunit: ~8.0|~9.0|^10.5
• squizlabs/php_codesniffer: ^3.7
• timacdonald/log-fake: ^2.1

MIT

• php
• Guzzle
• laravel

README

Structure the logic around Guzzle API requests into object-oriented classes

What?

We maintain an application that is reliant on dozens of REST APIs, most of which do not have SDKs.

We love Guzzle! But most of the documentation assumes that making a request is "easy," just a few lines of code.

But we've discovered in our own use that the structure around that Guzzle request can run into hundreds of lines, managing pre-requisites like authentication, converting data between our internal types and our partners' types, etc.

So we created AbstractRequest as a standardized way to:

1. Organize logic into classes.
2. Provide swappable traits for encoding and decoding (XML, JSON, forms, even simplified GraphQL!)
3. Log everything using Laravel's File facade
4. Cache using Laravel's Cache facade (with a simple automatic cache key generator)
5. Provide a structure for chainable prerequisites (like authentication)
6. Provide a structure for catching exceptions and parsing responses back into your internal logic
7. Let you defer decisions about call order or synchronous/asynchronous processing to the user of the request class

Running the Tests

Install the dev dependencies:

composer install

Then run phpunit from the root of the project:

./vendor/bin/phpunit