Pyramid addon for OpenAPI3 validation
Validate Pyramid views against an OpenAPI 3.0 document
Peace of Mind
The reason this package exists is to give you peace of mind when providing a RESTful API. Instead of chasing down preventable bugs and saying sorry to consumers, you can focus on more important things in life.
- Your API documentation is never out-of-date, since it is generated out of the API document that you write.
- The documentation comes with try-it-out examples for every endpoint in your API. You don't have to provide (and maintain)
curlcommands to showcase how your API works. Users can try it themselves, right in their browsers.
- Your API document is always valid, since your Pyramid app won't even start if the document is not according to OpenAPI 3.0 specification.
- Automatic request payload validation and sanitization. Your views do not require any code for validation and input sanitation. Your view code only deals with business logic. Tons of tests never need to be written since every request, and its payload, is validated against your API document before it reaches your view code.
- Your API responses always match your API document. Every response from your view is validated against your document and a
500 Internal Server Erroris returned if the response does not exactly match what your document says the output of a certain API endpoint should be. This decreases the effects of the Hyrum's Law.
- A single source of truth. Because of the checks outlined above you can be sure that whatever your API document says is in fact what is going on in reality. You have a single source of truth to consult when asking an API related question, such as "Remind me again, which fields does the endpoint /user/info return?".
- Based on Pyramid, a mature Python Web framework. Companies such as Mozilla, Yelp, RollBar and SurveyMonkey trust Pyramid, and the new pypi.org runs on Pyramid too. Pyramid is thoroughly tested and documented, providing flexibility, performance, and a large ecosystem of high-quality add-ons.
- Validates your API document (for example,
openapi.json) against the OpenAPI 3.0 specification using the openapi-spec-validator.
- Generates and serves the Swagger try-it-out documentation for your API.
- Validates incoming requests and outgoing responses against your API document using openapi-core.
pyramid_openapi3as a dependency in your Pyramid project.
Include the following lines:
config.include("pyramid_openapi3") config.pyramid_openapi3_spec('openapi.yaml', route='/api/v1/openapi.yaml') config.pyramid_openapi3_add_explorer(route='/api/v1/')
- Use the
openapiview predicate to enable request/response validation:
@view_config(route_name="foobar", openapi=True, renderer='json') def myview(request): return request.openapi_validated.parameters
request.openapi_validated is available with two fields:
For responses, if the payload does not match the API document, an exception is raised.
Relative File References in Spec
A feature introduced in OpenApi3 is the ability to use
$ref links to external files (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#referenceObject).
In order to use this you must ensure that you have all of your spec files in a given directory (ensure that you do not have any code in this directory as all the files in it are exposed as static files), then replace the
pyramid_openapi3_spec call that you did in Getting Started with the following:
- Do not set the
pyramid_openapi3_spec_directoryto the same value as the
routethat you set for
pyramid_openapi3_spec_directoryshould not contain any file extensions as this becomes the root for all of the files in your specified
- You cannot use
pyramid_openapi3_specin the same app.
Endpoints / Request / Response Validation
pyramid_openapi3 are a few validation features:
- incoming request validation (i.e. what a client sends to your app)
- outgoing response validation (i.e. what your app sends to a client)
- endpoint validation (i.e. your app registers routes for all defined API endpoints)
These features are enabled as a default, but you can disable them if you need to:
config.registry.settings["pyramid_openapi3.enable_endpoint_validation"] = False config.registry.settings["pyramid_openapi3.enable_request_validation"] = False config.registry.settings["pyramid_openapi3.enable_response_validation"] = False
Warning: Disabling request validation will result in
request.openapi_validatedno longer being available to use.
Demo / Examples
There are three examples provided with this package:
- A fairly simple single-file app providing a Hello World API.
- A slightly more built-out app providing a TODO app API.
- Another TODO app API, defined using a YAML spec split into multiple files.
Both examples come with tests that exhibit pyramid_openapi's error handling and validation capabilities.
A fully built-out app, with 100% test coverage, providing a RealWorld.io API is available at niteoweb/pyramid-realworld-example-app. It is a Heroku-deployable Pyramid app that provides an API for a Medium.com-like social app. You are encouraged to use it as a scaffold for your next project.
The authors of pyramid_openapi3 believe that the approach of validating a manually-written API document is superior to the approach of generating the API document from Python code. Here are the reasons:
a) Both generation and validation against a document are lossy processes. The underlying libraries running the generation/validation will always have something missing. Either a feature from the latest OpenAPI specification, or an implementation bug. Having to fork the underlying library in order to generate the part of your API document that might only be needed for the frontend is unfortunate.
Validation on the other hand allows one to skip parts of validation that are not supported yet, and not block a team from shipping the document.
b) Validation approach does sacrifice DRY-ness, one has to write the API document and then the (view) code in Pyramid. Feels a bit redundant at first. However, this provides a clear separation between the intent and the implementation.
c) Generation approach has the drawback of having to write Python code even for parts of the API document that the Pyramid backend does not handle, as it might be handled by a different system, or be specific only to documentation or only to the client side of the API. This bloats your Pyramid codebase with code that does not belong there.
You need to have pipenv and Python 3.7 or 3.8 installed on your machine. Then you can run:
$ make tests
These packages tackle the same problem-space:
- pyramid_oas3 seems to do things very similarly to pyramid_openapi3, but the documentation is not in English and we sadly can't fully understand what it does just reading the code.
- pyramid_swagger does a similar thing, but for Swagger 2.0 documents.
- connexion takes the same "write spec first, code second" approach as pyramid_openapi3, but is based on Flask.
- bottle-swagger takes the same "write spec first, code second" approach too, but is based on Bottle.
- pyramid_apispec uses generation with help of apispec and marshmallow validation library. See above why we prefer validation instead of generation.
We do our best to follow the rules below.
- Support the latest two releases of Python, currently Python 3.7 and 3.8.
- Support only a single release of
openapi-coreand its sub-dependencies. See
Pipfile.lockfor a frozen-in-time known-good-set of all dependencies.
Use in the wild
A couple of projects that use pyramid_openapi3 in production:
- WooCart API - User control panel for WooCart Managed WooCommerce service.
- Kafkai API - User control panel for Kafkai text generation service.
Allow setting permission for explorer and spec view. [sweh]
Allow multiple OpenApis in one pyramid application. [sweh]
Fix for route validation when used with pyramid route_prefix_context. [damonhook]
- Support for endpoint validation of prefixed routes. [zupo]
- Support disabling of endpoint validation via INI files. [zupo]
Allow relative file
$reflinks in OpenApi spec, refs #93. [damonhook]
Validate that all endpoints in the spec have a registered route, refs #21. [phrfpeixoto]
Add support for openapi-core 0.13.4. [sjiekak]
Add the ability to toggle request/response validation independently through registry settings. [damonhook]
- Brown-bag release. [zupo]
Raise a warning when a bad API spec causes validation errors to be discarded. [matthewwilkes]
custom_formatterssupport in latest openapi-core 0.13.3. [simondale00]
Declare a minimal supported version of openapi-core. [zupo]
- Fix extract_errors to support lists, refs #75. [zupo]
Log Response validation errors as errors, instead of warnings. [zupo]
Log Request validation errors as warnings, instead of infos. [zupo]
Better support for handling apps mounted at subpaths. [mmerickel]
Pass the response into the response validation exception to support use-cases where we can return the response but log the errors. [mmerickel]
Reload development server also when YAML file changes. [mmerickel]
- Better support for custom formatters and a test showcasing how to use them. [zupo]
- Bad JWT tokens should result in 401 instead of 400. [zupo]
- Fix a regression with relative
openapi.yaml. Refs https://github.com/p1c2u/openapi-core/issues/218. [zupo]
[BREAKING CHANGE] Move
examples/todoappinto the main package so it becomes a first-class citizen and people can use it without copy/pasting. If you need custom JSON rendering, you can provide your own
pyramid_openapi3_extract_errorsconfig setting. [zupo]
0.13.xwhich brings a complete rewrite of the validation mechanism that is now based on
jsonschemalibrary. This manifests as different validation error messages.
[BREAKING CHANGE] By default,
openapi-coreno longer creates models from validated data, but returns
dicts. More info on https://github.com/p1c2u/openapi-core/issues/205 [zupo]
- Pin openapi-core dependency to a sub 0.12.0 version, to avoid regressions with validation. Details on https://github.com/p1c2u/openapi-core/issues/160 [zupo]
Fix handling parameters in Headers and Cookies. [gweis]
Introduce RequestValidationError and ResponseValidationError exceptions in favor of pyramid_openapi3_validation_error_view directive. [gweis]
- Added type hints. [zupo]
- Added additional references to other packages covering the same problem-space. [zupo]
- Moved repo to Pylons GitHub organization. [stevepiercy, zupo]
- Added a more built-out TODO-app example. [zupo]
- Fix for double-registering views. [zupo]
- Added a single-file example. [zupo]
- Tweaking the release process. [zupo]
- Added a bunch of tests. [zupo]
- Automatic releases via CircleCI. [zupo]
- Initial release. [zupo]
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size pyramid_openapi3-0.11-py2.py3-none-any.whl (30.1 kB)||File type Wheel||Python version py2.py3||Upload date||Hashes View|
|Filename, size pyramid_openapi3-0.11.tar.gz (33.4 kB)||File type Source||Python version None||Upload date||Hashes View|
Hashes for pyramid_openapi3-0.11-py2.py3-none-any.whl