Download the PHP package sudiptochoudhury/php-api-client-forge without Composer

Basics

That should be it. Nothing else is required. All the API endpoint will be intelligently converted to functions of this class. For example, if you have an endpoint [GET]/products, you will get a getProducts function. Here are some more examples:

Tried best to normalize the singulars and plurals.

There can be cases when the API endpoint structure is same as the another but the data passed to it determines a different action altogether. Ideally, this should not happen but not all API enpoints are ideally created. So, an endpoint like [get]/products?filter_by=active along with another endpoint [get]/products will have the same name. To keep both, the default behaviour is to add an _ before the duplicate name. However, you can add filters or hooks to completely change the duplicate name to something else.

Installation

Requirements

• Any flavour of PHP 7.0+ should do

Install With Composer

Importing Postman JSON

Export your Postman Collection using COllecton v2.1 format. It will be exported as JSON. Give the file a name, say postman.json and keep it inside a folder in your project.

Next, extend Import class (recommended) or may use it directly.

By Extending the Import class

You are ready to import. That's pretty much it (though there are tons of configurable options and hooks... we will come to that soon).

Now, let's import in some other part of your codebase.

Done!

Directly using parent class

It's even simpler (though)

Simpler, eh!

You will find a new .json, a new .md and a new .php file to server you well in your API venture forward.

The .json file is obviously based on data structure required to create a GuzzleHttp\Command\Guzzle\Description object.

The .php file has phpDoc @method definitions and may look something similar to

You can copy the method definitions parts to yor API class extended from the Client class.

The .md file is a markdown file with a table containing details of the API functions, equivalent endpoints, parameters, default values for parameters (if defined) and description - all derived from the Postman json file.

However, I would recommend to use the extend option as you will get a plethora of options to hook into various sections of parent code while the conversion of the Postman data to Guzzle Description is undergoing. You may want to add default values or change a name or change description or skip some items. All can be done by overriding functions of Import parent class and defining custom filter functions.

What are custom filter function?!!!

Well, let's pick an example. Let's say you see you want to change the duplicate function name for [get]/products as I stated an example in previous section. By default, the duplicate name will be set to _getProducts (remember? by default adding a _ before the name).

Now, in your extended Import class just define this

This is a filter function. The name must start with filter followed by the filter name and can then optionally add an _ and anything you want after that, just in case you want to define multiple functions for the same filter (like - filterFinalName_xxx or filterFinalName_001).

Each filter function will receive the value to be modified in the first parameter. The optional second parameter will be an associative array of helper data items that may help in determining logic of how the filter can be applied. At times it may also be the source of data to build documentation layouts. For example, the markdown API table is generated via a default filter. You can override it to generate the API table in your own way. May be you do not like table structure, you may devise you own structure. Sky is the limit. Additionally, there are a lot of filters dedicated to create a complete markdown documentation with sections like title, menu, description, table, header, footer, install, even donate and contact. Just tap into the desired layout filters and fill in your own content.

The table below gives you details of all the filters.

But before that, you can also do similar things by totally overriding the parent's functions. For example, readApiName can be overridden to extend or replace existing logic to detect a function name with your own logic. However, filters help in changing things in a granular way. There can be 10 filters applied to a single function you wan to override and you may need to just use one filter out of them instead of writing a big bunch of overriding code. Of course, choice is yours.