You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Manual editing of the YAML has led to some things that make the OpenAPI specification far less useful than it could otherwise be. For example, when retrieving a tesTask from the GET /task/{id} endpoint, the fields that are returned are dependent on the view query parameter. However, if you look at the definition of the schema for tesTask (which the OpenAPI specification indicates is the only valid response returned from that endpoint), it requires that the executors key is always present. This is actually not the case— in fact, the default behavior of the specification only return the id and state keys within that object.
This, in turn, makes it very difficult to use off the shelf (for example, no libraries that autogenerate bindings using the OpenAPI spec can be used).
For what it's worth, we auto-generated the specification using utoipa during the design of the CCDI Federation API, and it was really a pleasant experience (and also had the side benefit of having a Rust implementation that worked right out of the box). There are probably other ways to do it, just giving an example of where I've done this with success.
The text was updated successfully, but these errors were encountered:
I could swear that I wrote an issue for the inconsistent model definition for tesTask with respect to executors a long time ago, but I don't find it anymore - neither in the open, nor the closed issues. Any idea why that could be, @kellrott?
On the topic: Might well be worth to check out for TES 2.0 👍
Manual editing of the YAML has led to some things that make the OpenAPI specification far less useful than it could otherwise be. For example, when retrieving a
tesTask
from theGET /task/{id}
endpoint, the fields that are returned are dependent on theview
query parameter. However, if you look at the definition of the schema fortesTask
(which the OpenAPI specification indicates is the only valid response returned from that endpoint), it requires that theexecutors
key is always present. This is actually not the case— in fact, the default behavior of the specification only return theid
andstate
keys within that object.This, in turn, makes it very difficult to use off the shelf (for example, no libraries that autogenerate bindings using the OpenAPI spec can be used).
For what it's worth, we auto-generated the specification using
utoipa
during the design of the CCDI Federation API, and it was really a pleasant experience (and also had the side benefit of having a Rust implementation that worked right out of the box). There are probably other ways to do it, just giving an example of where I've done this with success.The text was updated successfully, but these errors were encountered: