PHPackages                             reindert-vetter/api-version-control - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [API Development](/categories/api)
4. /
5. reindert-vetter/api-version-control

ActiveLibrary[API Development](/categories/api)

reindert-vetter/api-version-control
===================================

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

2.3.3(3mo ago)1671.0M↓45%7MITPHPPHP >=7.1CI failing

Since Aug 18Pushed 3mo ago3 watchersCompare

[ Source](https://github.com/reindert-vetter/api-version-control)[ Packagist](https://packagist.org/packages/reindert-vetter/api-version-control)[ Docs](https://github.com/reindert-vetter/api-version-control)[ RSS](/packages/reindert-vetter-api-version-control/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (10)Dependencies (2)Versions (31)Used By (0)

API Version Control
===================

[](#api-version-control)

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

For news, follow me on [Twitter](https://twitter.com/ReindertVetter).

[How to install](#install)

Two ways to manage the versions of your endpoints
-------------------------------------------------

[](#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](#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](#version-middleware).

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

Benefits
--------

[](#benefits)

Version StatementVersion MiddlewareUpgrading 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
----------

[](#how-to-use)

### Releases

[](#releases)

In api\_version\_control.php config file you will see releases with an array of versions:

```
    'releases' => [

        'orders.index' => [
            '