OpenAPITools / OpenAPITools/openapi-generator

[REQ] [All languages] [Clients and servers] Generate built-in assertions for inter-parameter dependencies

Open
#8,722 5 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Is your feature request related to a problem? Please describe.

For a long time, OpenAPI has not supported the specification of inter-parameter dependencies, even though there's an open issue requesting support for it. This issue has become the most upvoted of all times in the OpenAPI repository.

An example of an inter-parameter dependency is "if parameter p1 is used, then p2 must be set to 'A'".

If these dependencies could be expressed in a machine-readable way, it would be possible to automate lots of things, including the generation of the source code in charge of validating these dependencies in clients and servers.

We have recently proposed an alternative to specify and automatically analyze these dependencies. It is all summed up in the following two Medium posts, for if you have interest:

  1. Inter-parameter dependencies in REST APIs (5-min read).
  2. Handling inter-parameter dependencies in REST APIs with IDL4OAS (7-min read).

With our proposal, it is possible to specify inter-parameter dependencies using IDL, a DSL specifically tailored for expressing inter-parameter dependencies in web APIs. What I would like to propose in this feature request is to automatically generate built-in assertions in the source code (client or server, any programming language) based on the dependencies expressed in IDL.

Describe the solution you'd like

We have implemented IDL as an Xtext DSL. Since it's written in Java, and so is OpenAPI generator, I think we could use the IDL parser for generating the assertions in the code, based on the IDL dependencies. For example, if we found a dependency like the following one:

ZeroOrOne(p1, p2);

We would write the following assertion in a Java server:

if (p1 != null && p2 != null)
    throw new BadRequestException("Parameters p1 and p2 cannot be used together");
// Otherwise, continue business logic

Additional context

The two Medium posts from above summarize pretty much everything there's to know about inter-parameter dependencies. Here's a list of some other resources that you may find interesting:

  1. IDL repository, including examples of IDL dependencies: https://github.com/isa-group/IDL
  2. IDL repository, to be used as a Maven dependency (e.g., in this project): https://github.com/isa-group/IDL-mvn-dep
  3. Research paper about the specification and analysis of these inter-parameter dependencies: https://www.researchgate.net/publication/348280988_Specification_and_Automated_Analysis_of_Inter-Parameter_Dependencies_in_Web_APIs
  4. Example of an OpenAPI specification using IDL ("x-dependencies" extension):
paths:
  /example/route:
    get:
      operationId: exampleOperation
      parameters:
        - in: query
          type: boolean
          required: false
          name: p1
        - in: query
          type: integer
          required: false
          name: p2
        - in: query
          type: string
          required: false
          name: p3
      x-dependencies:
        - Or(p1, p2, p3);
        - IF p1==true THEN p2;

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the referenced IDL Xtext parser, the IDL Maven dependency, and the x-dependencies OpenAPI example to understand how dependencies are represented. Done means generating appropriate built-in assertions for declared inter-parameter dependencies across client and server outputs and supported languages.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, openapi
Domain
api, backend-api-design, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.