Download the PHP package webparking/laravel-openapi-validator without Composer
On this page you can find all versions of the php package webparking/laravel-openapi-validator. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download webparking/laravel-openapi-validator
More information about webparking/laravel-openapi-validator
Files in webparking/laravel-openapi-validator
Package laravel-openapi-validator
Short Description An OpenAPI documentation validator using your existing Laravel tests
License MIT
FAQ
Example:
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 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.
Informations about the package laravel-openapi-validator
laravel-openapi-validator
An OpenAPI documentation validator using your existing Laravel tests.
TL;DR
composer require --dev webparking/laravel-openapi-validator
The problem
When creating and maintaining an HTTP REST API, you want to make sure it works well and is well documented. We consider it essential to be able to check both automatically.
What we tried before
- We made a system that would generate tests from the API documentation. For the majority of tests, it worked. But having a simple way to include edge cases in your tests is next to impossible. For example: there's an endpoint that returns a 500 status code when called with certain input. You've fixed the bug and want to add a test to make sure it actually is and stays fixed. To do that, you'd have to include an error-case in your docs. You don't want to live in a hacky world like that.
- We made a system that would generate documentation based on the application's code. First of all, it would be very difficult to explain nuances and abstract concepts in your documentation, as they don't have a formal place in the application. We'd have to split the documentation in two: the technical spec generated from code and the complimentary explanations in a wiki of some kind. And yes, they'd get out of sync over time. Second, your application code needs to be very very structured in order to accomplish this. Maintaining quality by consistency is a big thing for us, but in practice there are always one or two edge cases where it's actually better to deviate.
Our solution
We combined Laravel HTTP testing with ThePHPLeague's OpenAPI PSR7 validator by overriding MakesHttpRequests#call. Before executing the request, we have it validated against the OpenAPI documentation. And before returning the response, we have that validated too. Exceptions are thrown for any problems found.
This solution has enabled us to use both OpenAPI and HTTP tests to the fullest; no compromises needed.
Usage
Simply use the ValidatesHttpMessagesAgainstDocs in your test class. We generally do this on the project level TestCase.
The default index file for the docs is docs/index.yaml, but you're free to override that by setting the yamlPath property.
You may want to exclude certain URI's from validation. Set the ignoredUris property to do this.
All versions of laravel-openapi-validator with dependencies
league/openapi-psr7-validator Version ^0.17
nyholm/psr7 Version ^1.5
symfony/psr-http-message-bridge Version ^2.1
php Version ^8.1|^8.2