LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub

Customize Status

How to customize the output format for Error Status response

Light-4j Status module is an object that models the error response and is constructed from error code defined in status.yml config file. The framework provides some error code and we are expecting the API itself provide some service specific error code. For more detail on the Status module, please check the cross-cutting concerns section.

The default output of error status is a JSON string with several properties flattened in a map. Here is an example.


{
  "statusCode": 401,
  "code": "ERR10001",
  "message": "AUTH_TOKEN_EXPIRED",
  "description": "Jwt token in authorization header expired"
}

One of our customers has a special format for error code along with some other meta data and they ask if the output format can be changed. And the following is the solution for users want to use customized serializer.

First we provide an interface called StatusSerializer

package com.networknt.status;

/**
 * Interface to allow custom serialization for a Status.
 * 
 * Framework users can define their own format to return an error message to a consumer
 * 
 * @author Dan Dobrin
 */
public interface StatusSerializer {
	/**
	 * Serialize the status and provide a custom format in the iomplementing class
	 * 
	 * @param status The status to be serialized
	 * @return the format Status object, to be serialized and returned to the consumer
	 */
	public String serializeStatus(Status status);
}

Second you need to implement above interface with your format. Here is an example.

public class ErrorRootStatusSerializer implements StatusSerializer {

	@Override
	public String serializeStatus(Status status) {
		return "{ \"error\" : {\"statusCode\":" + status.getStatusCode()
        + ",\"code\":\"" + status.getCode()
        + "\",\"message\":\""
        + status.getMessage() + "\",\"description\":\""
        + status.getDescription() + "\"} }";
	}

}

Third you add the mapping between the interface to implementation in service.yml

# Singleton service factory configuration
singletons:
  - com.networknt.status.StatusSerializer:
    - com.networknt.status.ErrorRootStatusSerializer

Now, the ErrorRootStatusSerializer will override the default one and the output will be something like this.

{
  "error": {
    "statusCode": 401,
    "code": "ERR10001",
    "message": "AUTH_TOKEN_EXPIRED",
    "description": "Jwt token in authorization header expired"
  }
}

As you can see that there is an error object that contains all the properties in Status object. You can change the format to anything you want and the IoC service module will be responsible to load your implementation from service.yml config file.

  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • 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
    • Spring Boot Servlet
  • 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
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • 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
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Customize Status” was last updated: July 5, 2021: fixes #275 checked and corrected grammar/spelling for majority of pages (#276) (b3bbb7b)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute