Other: API: Needs Fix: OpenAPI schema definition's all response object properties are OPTIONAL
CompletedWe can download OpenAPI schema from https://developers.fivetran.com/openapi/reference/v1/overview/
`properties` of JSON schema is OPTIONAL by default and if it is REQUIRED, it is necessary to add `required` which is list of required property names.
source: https://json-schema.org/understanding-json-schema/reference/object.html#required-properties
By default, the properties defined by the
properties
keyword are not required. However, one can provide a list of required properties using therequired
keyword.
For example, GET response of /v1/users is defined as following.
"responses": {
"200": {
"description": "Successful response",
"content": {
"application/json": {
"schema": {
"properties": {
"code": {
"type": "string",
"description": "Response status code"
},
"message": {
"type": "string",
"description": "Response status text"
},
"data": {
"properties": {
"items": {
"type": "array",
"description": "The collection of return items",
"items": {
"$ref": "#/components/schemas/UserResponse"
}
},
"nextCursor": {
"type": "string",
"description": "The value of the cursor parameter for the next page"
}
}
}
}
}
}
}
}
}
When I use this as client (like with codegen) I need to check existence of every properties to strictly follow typings.
More specific example, in typescript, it is expressed as following.
type Response = {
code?: string;
message?: string;
data?: {
items?: UserResponse[];
nextCursor?: string;
};
};
NOTE: Imagine UserResponse is defined in another place.
nextCursor could be actually OPTIONAL.
And if I use the value of this type, I should check everything.
if (response.data != null) {
if (response.data.items != null) {
for (const item of response.data.items) {
if (item.<some item's prop> != null) ...;
if (item.<other item's prop> != null) ...;
if (item.<other item's prop> != null) ...;
}
}
}
To solve this, I want it to add `required` correctly.
https://json-schema.org/understanding-json-schema/reference/object.html#required-properties
---
Or are they all actually optional?
-
Official comment
Edit 6/14/2023: This is now live! Check out our latest OpenAPI definition here.
Hey 哲平 川口!
Thank you for writing in! Our OpenAPI schema is a near term focus for us and I appreciate that you are using it and wanting us to make it better!
Are you just generating an Typescript SDK for your use?
Please keep writing in about any other issues you find, we'll be fixing them and focusing on providing a more robust definition soon!
Jimmy
-
I found other problems.
- Around line 7913 (same for 7988, 8047), written as " AWS_EU_WEST_2", it starts with single space.
"region": {
"type": "string",
"description": "Data processing location. This is where Fivetran will operate and run computation on data.",
"example": ">- optional_US_by_default: US, EU, APAC (Australia), UK, CANADA, SINGAPORE",
"enum": [
"GCP_US_EAST4",
"GCP_US_WEST1",
"GCP_EUROPE_WEST3",
"GCP_AUSTRALIA_SOUTHEAST1",
"GCP_NORTHAMERICA_NORTHEAST1",
"GCP_EUROPE_WEST2",
"GCP_ASIA_SOUTHEAST1",
"AWS_US_EAST_1",
"AWS_US_EAST_2",
"AWS_US_WEST_2",
"AWS_AP_SOUTHEAST_2",
"AWS_EU_CENTRAL_1",
"AWS_EU_WEST_1",
" AWS_EU_WEST_2",
"AZURE_EASTUS2",
"AZURE_AUSTRALIAEAST",
"GCP_ASIA_SOUTH1"
]
},- Same place with above, it's lacking some regions like GCP_ASIA_NORTHEAST1
- Many response properties are nullable but any of types neither does include "null" as type nor "nullable" is not specified.
NOTE: null and key omitting(=optional) are different things in OpenAPI
NOTE: "type": "null" is supported from 3.1 but little confusing ( refer to https://github.com/OAI/OpenAPI-Specification/issues/3148 ) intertwined by its historical reasons... so nullable sounds strait-forward.. but it is not json schema native... oops... and it's removed since 3.1 ( refer to https://github.com/OAI/OpenAPI-Specification/blob/946f590590af84af7b90e09ecf20e0b345258ef7/proposals/2019-10-31-Clarify-Nullable.md ). "type": "null" is better for future compatibility.
-
Hi Jimmy.
Thanks for replying!
Are you just generating an Typescript SDK for your use?
Yes! In my team, we're evaluating Fivetran for the product.
I'm using https://github.com/astahmer/openapi-zod-client now for code generating, but anything would work.
I'm also making CLI for the team. I want to consult with company to make it open if possible (and if I have enough time to publish).
-
I'd love to understand what problems you are solving by generating a typescript client. How much of our API do you plan to use? What does the SDK allow your team to do better with our API?
Thank you!
Jimmy
-
This is now live, thank you for raising the issue! Please check out the latest OpenAPI definition here.
Please sign in to leave a comment.
Comments
5 comments