Download the PHP package red-explosion/vermillion without Composer
On this page you can find all versions of the php package red-explosion/vermillion. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download red-explosion/vermillion
More information about red-explosion/vermillion
Files in red-explosion/vermillion
Package vermillion
Short Description API Versioning tools for Laravel apps
License Apache-2.0
Informations about the package vermillion
Vermillion 🍂
An API versioning toolkit for Laravel applications️
- What you get
- Installation
- Configuration
- Choose an API version format
- Choose an API versioning scheme
- Specify supported versions
- Basic Usage
- How to define versioned routes
- Route URL generation
- Versioning API responses
- Header-based versioning & MissingVersionException
- Advanced Usage
- Using your own custom versioning scheme
- Using your own custom version format
- Version anything using VersionedSet
-
PHPStan
What you get
- An
ApiVersionservice you can use to detect requested API version & to perform comparison between versions. - You can have as many as API versions you need (10 versions? 1,000? No judgement here.) without exploding your app's route collection. Keep the router's time to match versioned routes constant, and your developers sane: no more route-name pollution–it's
user.list, notusers.list.v1,users.list.v3,users.list.v21, etc. - A scalable way to version your API responses. Take your existing
JsonResources and make them support multiple API versions by employing reverse migrations. - A declarative utility API that you can use for anything. Just specify logical variations that apply to a range of API versions, and programmatically resolve the correct variant whenever you need it.
- An extensible versioning scheme system to define exactly how you wish clients to request an API version. Has built-in support for URI prefixes (e.g.
/v2/...) or HTTP headers (e.g.X-Api-Version: ...), and you can easily build your own. - An extensible versioning format system to define exactly what API versions you understand. Has built-in support for numeric versions (e.g.
v2) and date versions (e.g.2022-11-01), and its also dang easy to roll your own.
Installation
Configuration
First, ensure that RedExplosion\Vermillion\VermillionServiceProvider is registered in your app. Sometimes it's automatic (via package discovery), sometimes it's not, so please double-check your app configuration.
Run this to generate a copy of the vermillion config:
Choose an API version format
There are many ways versions are notated e.g. SemVer. There is built-in support for two formats you can choose from:
major- Stands for "major versions only" e.g.2date- Versions are in date format e.g.2020-02-24
You can also roll your own. See "Use your own versioning format" under Advanced Usage.
Choose an API versioning scheme
You can pick a way clients can specify API versions:
url_prefix- API version will be specified in URLs e.g./api/v2/helloheader- API version will be specified in the request header e.g.X-Api-Version: 2020-02-01-
You can also roll your own. See "Use your own versioning scheme" under Advanced Usage.
Specify supported versions
You can configure min, latest, and max versions independently in the config file:
- Minimum version (e.g.
'min' => '1') - The oldest version your API currently supports. Any versioned routes requested with a version lesser than theminversion will automatically 404. - Latest version (e.g.
'latest' => '2') - The latest stable version your API supports. This will be the version used when nothing was not explicitly specified or when none can be inferred e.g. when generating URLs when not in a versioned route context, in async jobs, etc. - Maximum version (e.g.
'max' => '3') - The maximum version your API supports. Anything that one would consider alpha, beta, or RC are better suited in versions that is greaterlatest. This the max API version clients can ask for i.e. Any versioned routes requested with a greater version than themaxversion will automatically 404.
Basic Usage
How to define versioned routes
Route URL generation
When using url_prefix as versioning scheme, the URL generator will be automatically configured to use the current active version.
If there is no active version e.g. code executed within an unversioned route, the latest version will be used (defined in config('vermillion.latest')).
If you wish to generate a route for another API version, specify the apiVersion option:
ApiVersion service
You can specify RedExplosion\Vermillion\ApiVersion as a dependency and you will get a reference to the current active (or latest) API version object:
NOTE: You need to type-hint the RedExplosion\Vermillion\ApiVersion abstract, NOT any of concrete implementations in RedExplosion\Vermillion\Formats\* namespace!
Versioning API responses
You can use the RedExplosion\Vermillion\Traits\JsonResource\WithReverseMigrations trait to support Stripe-like data versioning via "reverse migrations":
Header-based versioning & MissingVersionException
By default, using the header scheme will require that requests have the header present when its for a versioned route.
This manifests as a MissingVersionException thrown, which you will want to render appropriately:
Advanced Usage
Using your own custom versioning scheme
If you need to determine the API version to use given an HTTP request, you will need to write your own scheme by implementing RedExplosion\Vermillion\VersioningScheme contract.
Specify your custom versioning scheme's FQCN in the versioning configuration:
Using your own custom version format
-
You can implement your own versioning format e.g. SemVer by extending the
RedExplosion\Vermillion\ApiVersionabstract. All that is required for your newApiVersiontype is to provide an integer representation of your version strings. This is used by the library to compute the ordinality between versions, which is what is all that is needed for everything to work. -
You will need to implement a
RedExplosion\Vermillion\VersionNormalizerclass that is responsible for converting a version string to an instance of your customApiVersionsub-class. It MUST support your custom version strings as input, as well as the customApiVersionsub-class. It MUST throwBadVersionFormatExceptionif it is provided an input that it cannot convert into a validApiVersionfor according to your custom version format spec. - Specify the FQCN of your normalizer as
vermillion.normalizerconfig value e.g.
Version anything using VersionedSet
A powerful way to model conditional logic is through the Strategy pattern, especially if there are many possible branches. This is often the case when supporting many API versions. The VersionedSet utility class
is specifically designed to make API version-based decisions easy to implement & manage:
PHPStan
Add this line to your phpstan.neon file to fill static analysis gaps around Route methods, etc.
All versions of vermillion with dependencies
illuminate/contracts Version ^9.0|^10.0
illuminate/routing Version ^9.0|^10.0
illuminate/support Version ^9.0|^10.0