Download the PHP package reindert-vetter/api-version-control without Composer

On this page you can find all versions of the php package reindert-vetter/api-version-control. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package api-version-control

API Version Control

A Laravel package to manage versions of endpoints in an elegant way.

For news, follow me on Twitter.

How to install

Two ways to manage the versions of your endpoints

Option 1: Version Statement

You probably use if statements to determine whether the code should be executed from a particular version. But what do you do if you want to run this code for 2 endpoints, one from version 2 and the other from version 3? This package offers a clean solution for this: Version Statement.

Option 2: Version Middleware

Legacy code can get in the way quickly. Do you therefore create multiple controllers to separate the old code from the new code? How do you do this if there are 10 versions at a given time? By then, will you also have 10 validation schemes and response classes for each endpoint? This package also offers a SOLID solution that goes even further than Version Statement: Version Middleware.

You can use Version Middleware and Version Statement together in one project

Benefits

Version Statement Version Middleware
Upgrading all endpoints or one specific endpoint. ✔️ ✔️
One overview of all versions with the adjustments. ✔️ ✔️
The controller (and further) always contains the latest version. ✔️
Old versions are only defined once. Once made, you don't have to worry about that anymore. ✔️

Note for Version Middleware: If you do not yet use a self-made middleware, you can debug from your controller. With Version Middleware, colleagues must now understand that (only with an old version of an endpoint) the code in a middleware also influences the rest of the code.

How To Use

Releases

In api_version_control.php config file you will see releases with an array of versions:

Route Match

You put the route names in the key of the releases array. The key must match the current route name. Use a | to match multiple route names. The package runs through the route names. If a match is found, it stops searching. The match contains Version Rules. If no Route Name match can be found, default will be used. That way you can update all your other endpoints. To match versions on all endpoints, you can use the all key.

You have to specify the route names in your router. Example: Route::get('orders', 'OrdersController@index')->name('orders.index');. When using you use Resource Controllers, the names are determined automatically. For more information, see the Laravel documentation.

Version Rules

Version Rules contains a string with an operator and a version ('<=2'). Supported operators are: <, <=, >, >=, ==, !=. All classes within the Version Rules with a match are used. The classes within Version rule are Version Middleware.

Version Statement

A Version Statement file looks like this:

If the file contains the trait \ReindertVetter\ApiVersionControl\Concerns\VersionStatement, then you can do the following in your source code:

Version Middleware

You process all requests and responses what is different from the latest version in middlewares. You can adjust the request with multiple middlewares to match the latest version. You can also adjust the format of a response in the Version Middleware.

A Version Middleware file (that changing the request) can looks like this:

A Version Middleware file (that changing the response) can looks like this:

Request and Resource Binding

You can bind a FormRequest or a Resource to handle other versions. That way you can more easily support different parameters with rules, and you can more easily support different resources. A controller that supports different versions could look like:

The $request can be either OrderIndexRequestV1 or OrderIndexRequestV2 and the $resource can be either OrderResourceV1 or OrderResourceV2. OrderIndexRequestV2 must extend the base class OrderIndexRequest. You can do the same for the resource class. When using the Bind middleware, then the configuration will look like this:

If it's not quite clear yet, post your question in the discussion.

Version Parser

Out of the box this package supports versions in the header accept and versions in the URI. But you can also create your own version parser. Specify this in api_version_control.php config file.

Install

  1. Run composer require reindert-vetter/api-version-control.
  2. Add ->middleware(['api', ApiVersionControl::class]) in your RouteServiceProvider.

If you are using URL Version Parser (which is the default) make sure the version variable is present in the url. For example:

Now the routes are only accessible with a version in the URL (eg /api/v2/products). Do you also want the endpoint to work without a version in the url? Then first define the routes without the version variable:

_You can see here that we prefix the route name with no_version. (for the routers without a version). You have to do that to avoid the error Another route is already using that name when caching the routers. Decide for yourself whether this is desirable for your application._

  1. Add \ReindertVetter\ApiVersionControl\ApiVersionControlServiceProvider::class to your providers in config/app.php
  2. Create a config file by running php artisan vendor:publish --provider='ReindertVetter\ApiVersionControl\ApiVersionControlServiceProvider'.
  3. Choose a Version parser or create one yourself.
  4. Run (when necessary) php artisan route:clear or php artisan route:cache

If it's not quite clear yet, post your question in the discussion.


All versions of api-version-control with dependencies

PHP Build Version
Package Version
Requires php Version >=7.1
illuminate/routing Version >=5.7.12
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package reindert-vetter/api-version-control contains the following files

Loading the files please wait ....