Various common problems when using JSON as a payload for API requests

The Jvax (JSON Verification and conversion/transformation) system processes all incoming requests before the cloud service receives an incoming request. Jvax is designed to handle various http://www.aliyun.com/zixun/aggregation/17253.html "> common problems" that occur when using JSON as a payload for API requests.

This paper presents a solution that addresses the problems that arise when cloud services and their users require JavaScript Object notation (JSON) payload validation and conversion. We refer to this infrastructure as JVAX (JSON verification and Conversion/transformation,json validation and transformation), which uses a configurable JSON schema to implement validation and transformation.

The development cycle of a cloud application with a JSON payload typically involves continuous upgrades and integrations. Adding or modifying each use case may require changing the JSON validation and transformation logic for the application. This makes applications more vulnerable, error-prone, and difficult to maintain.

In general, cloud services that provide the representational state transmits (REST) API perform a large amount of JSON payload validation and conversion work. The Jvax infrastructure is designed to be used to independently validate and transform the JSON workload of cloud services, so the Jvax system reduces the effort of the request-validation process, which is usually what the service provider must complete. At the same time, Jvax helps make using applications more reliable, and applications are easier to maintain.

Jvax uses a complex mechanism to describe the payload rules. Before we introduce the JVAX structure, let's look at an example.

Jvax Mode definition

Listing 1 shows a simple JSON payload: a Person object.

Listing 1. Sample input data for the person object

' person ': {"FirstName": "Krishna", "LastName": "Yadav" "Age": "PhoneNumber": "91-012-3456789"}

Listing 2 shows an example of a basic JSON pattern of the person object in Listing 1:

Listing 2. Jvax mode definition of person object

{"Person": {"type": "Object", "Properties": {"FirstName": {"type": "String", "category": "Mandatory"}, "LastName": {' type ': ' String ', ' Category ': ' Mandatory '}, ' age ': {' type ': ' Number ', ' Category ': ' Mandatory '}, ' PhoneNumber ': {' type ': ' String ', ' Category ': ' OPTIONAL '}}}

The JSON pattern in Listing 2 describes the various data types of the person object. Table 1 lists the types supported by Jvax:

Table 1. Supported Jvax field types

supported type input values sample string java.lang.String supported double quote string values. ' Type ': ' String ' Boolean true or False ' type ': ' Boolean ' object an ordered set of key/value pairs.

The
Properties indicator holds the description of these key/value pairs. ' Type ': ' Object ', ' properties ': {//Description of the collection} array an ordered sequence of values (this value can be a base type or another object type).


assume that these elements have the same type.

The
items indicator holds the description of the array. ' Type ': ' array ', ' items ': {//description of array elements} number Java.lang.number supported numeric ' type ': ' # '

In a payload, each field requires a value. For each field, the pattern applies a category. These categories use internal rules (implemented in the business logic of application code) to determine how Jvax handles field values. These rules support a method of overriding these values, which is important to prevent callers from setting invalid values. Table 1 shows the JAVX category and its associated processing rules:

Table 2. Jvax categories and their related processing rules

category description (for API users) Internal processing rules (yes = input supplied) (no = not provided in input) mandatory API request must provide this value. If yes, the value is used. If it is no, an error occurs. The OPTIONAL API request can optionally provide this value, and if no value is provided, the default value is used. If yes, the value is used. If it is no and a default value is provided in the pattern, the default value is used. If no, and no default value is provided in the pattern, no action is performed. RESERVED This field is for internal use only. All API input values are ignored and replaced with internal default values in the pattern. If yes, overrides are used with default values. If it is no, a key is created with a default value and populated. (There will be no errors in either of these cases.) Suppressed if a value is supplied, the value is ignored. If yes, the value is deleted. If no, no action is performed.

This pattern also supports the use of enumeration types, rule expressions, and custom validation mechanisms. Because schemas can refer to shared object definitions, Jvax can increase code reuse rates.

Jvax Design

The key concept in Jvax design is to pass these requests through a JVAX system before the service provider processes them. Figure 1 shows an overview of the Jvax components and how to associate them:

Figure 1. Jvax Overview

The basic steps reflected in Figure 1 include:

on the Jvax system, the service provider defines a JSON pattern that acts as an API payload template. This API is used by users to send the JSON payload to the Jvax system. Jvax validates and transforms the input payload according to the pattern. When an error occurs, Jvax responds to the user on behalf of the vendor. When the validation succeeds, Jvax redirects the request to the service provider.

Designing JSON Mode

The steps for defining the JSON pattern include:

The

service provider defines the APIs and the associated payload fields. The service provider defines patterns that reflect the API payload fields. The service provider defines the field type using the following rules: If the API requires a field, the service provider will mark it as mandatory. If you do not need a field, mark it as optional. A field that always has a specific set of values is marked as RESERVED. If the value of a field cannot be passed to the API, the field is marked as suppressed.

Figure 2 shows all the steps involved in the JSON pattern design:

Figure 2. To design a JSON pattern

Jvax Loading process

Figure 3 shows the enabling process for a Jvax system:

Figure 3. Jvax Loading process

In the process shown in Figure 3:

Jvax System reads the JSON payload provided by the service user. Jvax reads the JSON mode provided by the service provider for a specific API. Jvax tried to validate JSON mode. If an error is encountered, an error condition is returned and stopped. If the pattern is not valid, then Jvax will validate the JSON payload against the defined JSON schema. If the payload does not match the signature in JSON mode, an error condition is returned and stopped. If no errors occur during the validation of the payload, Jvax will (selectively) transform the input JSON payload according to the API needs. The service provider infrastructure will invoke the API and use it to send a response to the service user.

Configuration options

For the whole Jvax system, either stand-alone configuration or embedded configuration can be done. In a stand-alone configuration, Jvax is installed separately from the cloud service and runs as a separate process. In an embedded configuration, Jvax is embedded in an existing application, so you can share the same process space. Embedded configuration makes Jvax easy to deploy and configure, and avoids unnecessary hardware configuration costs.

Advantages of Jvax

The advantages of the Jvax solution include:

Easy to configure: The rule-based Jvax approach makes it easy to take advantage of business rules that can be constantly changing. Pluggable and scalable: rule-based Jvax methods can be embedded in the actual service or any other existing service agent. Or, when the payload is intercepted or censored, it is added as a separate agent. Easy to maintain: simply change the configuration without redeploying the service. Efficiency: Requests cannot reach the API unless these requests are valid. Therefore, this will reduce unnecessary processing overhead for service providers. Versioning support: Although the internal interface of the system may be changed by the service provider, Jvax provides a simpler way to maintain external interface compatibility. Document Support: Schema information can be directly translated into API documentation.

Concluding

JSON is widely used for data transfer between client applications and WEB servers, and JSON validation and conversion becomes increasingly important in the cloud era. For service providers and service users, the JAVX system may be a Boolean value that can help service providers reduce the maintenance effort involved in processing various JSON-formatted workloads. Service users can easily see the response from the Jvax system and modify their JSON payload accordingly.