LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

OpenAPI Validator

This handler is part of the light-rest-4j which is built on top of light-4j but focused on RESTful API only. Also, it only works with the OpenAPI 3.0 specification.

It encourages design driven implementation so OpenAPI specification should be done before the implementation starts. With the light-codegen generator, the server stub can be generated and start running within seconds. However, we cannot rely on the generator for validation as specification will be changed along the life cycle of the API. This is why we have provided a validator that works on top of the specification at runtime. In this way, the generator should only be used once, and the validator will take the latest specification and validate according to the specification at runtime.

Fail fast

As you may notice that our Status object only supports one code and message. This is the indication the framework validation is designed to fail fast. Whenever there is an error, the server will stop processing the request and return the error to the consumer immediately. There are two reasons on this design, and it is documented in fail-fast in the design section.

ValidatorHandler

It is the entry point of the validator, and it is injected during server startup if validator.yml enabled is true. By default, only RequestValidator will be called. Response validation should be done in the client module.

Configuration

From release 1.5.18, the light platform supports multiple chains of middleware handlers and multiple frameworks mixed in the same service instance. To have a validator configuration file for different frameworks, a new openapi-validator.yml with the same content has been introduced. The validator.yml is still loaded if openapi-validator.yml doesn’t exist for backward compatibility.

Here is an example of openapi-validator.yml

# This is specific OpenAPI validator configuration file. It is introduced to support multiple
# frameworks in the same server instance and it is recommended. If this file cannot be found,
# the generic validator.yml will be loaded as a fallback.
---
# Enable request validation. Response validation is not done on the server but client.
enabled: true
# Log error message if validation error occurs
logError: true

RequestValidator

It will validate the following:

  • uri
  • method
  • header
  • query parameters
  • path parameters
  • body if available

When necessary, json-schema-validator will be called to do json schema validation.

ResponseValidator

It will validate the following:

  • header
  • response code
  • body if available

when necessary, json-schema-validator will be called.

SchemaValidator

If a schema is defined in openapi.yaml or openapi.json, then the json-schema-validator will be called to validate the input against a JSON schema defined in draft v4.

Test

In order to test validator, the test suite starts a light-4j server and serves the petstore api for testing. It is a demo on how to unit test your API during development.

  • About Light Platform
    • Overview
    • What is Light
    • Features
    • Benefits
    • Principles
    • Roadmap
    • Articles
    • Videos
    • License
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • SOA
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Environment Segregation
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
    • Configs References
  • API Styles
    • Style Overview
    • Distributed session on IMDG
    • Eventuate - Event Sourcing and CQRS
    • Hybrid - Modularized Monolithic
    • REST - Representational state transfer
    • Saga - Distributed Transactions
    • Tram - Transactional Messaging
    • Web Server with Light Platform
    • Websocket with light platform
    • Single Page Application
    • GraphQL - A query language for your API
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Router
    • Introduction
    • Architecture
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • Light OAuth2
    • Services
    • Metrics and Alerts
    • Reference
    • Config Server
    • Tokenization
  • Tool Chain
    • Tool Chain Overview
    • Hugo Docs
    • Hugo Site
    • Hugo Netlify
    • Java keytool
    • Memory Monitoring
    • OpenAPI Parser
    • Minikube
    • Wrk
    • Light Bot
    • Light Codegen Reference
    • Kubernetes
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
    • Best Practices
    • Development Flow
    • Platform Developer
    • Develop Build
    • Application
    • Service Provider Developer
    • Service Consumer Developer
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Example
    • Example Overview
  • Tutorial
    • Tutorial Overview
    • Client Tutorial
    • Common Tutorial
    • Registry and Discovery
    • Middleware Handlers
    • OpenAPI 3.0 Petstore
    • Security Tutorial
    • Swagger 2.0 Petstore
    • Test light service
    • Light Codegen Tutorial
    • Restful Database Access
    • Light Oauth2 Tutorial
    • Microservices Chain Pattern
    • GraphQL Tutorial
    • Handler Routing Tutorial
    • Microservices Aggregate Pattern
    • Restful Tutorial
    • Hybrid Tutorial
    • Light Bot Tutorial
    • Microservices Branch Pattern
    • Tram Tutorial
    • Eventuate Tutorial
    • Light Portal Tutorial
    • Light Proxy Tutorial
    • Light Router Tutorial
  • Benchmark
    • Benchmark Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“OpenAPI Validator” was last updated: February 11, 2019: fixes #43 update light-rest-4j document to add dependencies (aca0f4b)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light Platform
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Example
  • Tutorial
  • Benchmark
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute