Generate relations in openapi.json

[KyDenZ]

Suggestion

When an entity contains a relationship attribute (hasMany, hasOne), this one is not generated in the openapi.json file.

Use Cases

I want to use, as part of React, the generator Typescript-axios. It generates the entities well, but without the relations.

Acceptance criteria

TBD - will be filled by the team.

[dhmlau]

@KyDenZ, could you please translate your use case to English? :)

@raymondfeng, what's your thought on this? Thanks.

[KyDenZ]

Yes, sorry :)

[bajtos]

I am confused.

Are you @KyDenZ asking the model schemas to include properties for accessing related models? We have recently added support for that, see #2631, #2630 and #3171.

Example usage:

https://github.com/strongloop/loopback-next/blob/c65b77f92468a9ae9948809bbcf24d25f05059f8/examples/todo-list/src/controllers/todo-list.controller.ts#L69-L89

Or do you perhaps refer to Link Object (the spec) that can be used to describe navigation from operations related to one model to operations related to another model?

Let's discuss & clarify.

[KyDenZ]

I did not think you had to add "include" to generate relationships in models in the openApi json.

Actually it works now. Thank you @bajtos !

One question: Is it possible to generate a single model that contains all the information (like the loopback generator 3 for Angular) with relations, id, attributes ... To avoid having dozens of models with long quite long name ?

[bajtos]

Actually it works now.

Great, I am glad for that 👍

Is it possible to generate a single model that contains all the information (like the loopback generator 3 for Angular) with relations, id, attributes ... To avoid having dozens of models with long quite long name?

I am afraid that's not possible if you want the OpenAPI spec to accurately describe the request & response schemas.

• find method can return related models in properties like products and owners. However, these properties are not valid when creating or updating data.
• When creating a new model instance, the id property is typically not allowed, because we want the database to generate it. However, all other endpoints support id in the data.
• When performing a partial update (PATCH), all properties are optional, because the client can select a subset of properties to update. Other write operations like create will reject requests where a required property is not provided.

I suppose you could modify your API to use the same schema with the following options:

• Allow id for create requests.
• Include relational properties.
• Make all properties optional.

This will simplify your client at the cost of reduced validations.