Added api call example

[yoavkatz]

No description provided.

[elronbandel]

Can we simplify that part in any way?

[yoavkatz]

I opened an issue about this (#1588) The current 'results.instance_scores.summary' is not usable because it prints too long lines. I think we want to change it to print in a different way, and then we could use it here.

[elronbandel]

This is a nice example that share a lot of similarity with Text to SQL.
In both cases there is (1) user query (2) api/database and that target is to translate the user query to the api/database language.
I think its worth looking at how the SQL was implemented: specifically:

(1) The database is defined by its unique identifier (in this case could be OpenAPI(url="https://petstore.swagger.io/v2/pets")
(2) the representation of the database to the model is determined by a dedicated type serializer (in this case it could be OpenAPISpecificationSerializer(format="json") # can be yaml)
(3) Metrics could also use deterministic verification like with. https://pypi.org/project/openapi-spec-validator/ that can use the OpenAPI directly to verify schema/syntax/execution

[yoavkatz]

This is a nice example that share a lot of similarity with Text to SQL. In both cases there is (1) user query (2) api/database and that target is to translate the user query to the api/database language. I think its worth looking at how the SQL was implemented: specifically:

(1) The database is defined by its unique identifier (in this case could be OpenAPI(url="https://petstore.swagger.io/v2/pets") (2) the representation of the database to the model is determined by a dedicated type serializer (in this case it could be OpenAPISpecificationSerializer(format="json") # can be yaml) (3) Metrics could also use deterministic verification like with. https://pypi.org/project/openapi-spec-validator/ that can use the OpenAPI directly to verify schema/syntax/execution

1. I wanted to keep this simple for now (I did it to show one of the users, who actually had their internal API spec representation). That's why I did not put the task in the catalog yet - and left it as a standalone example file - I felt it's not mature enough to be general.
   2.I agree a more elaborate approach could be done with a serializer for OpenAPI specs.
2. I think the above library validates the scheme (which I assume to be correct), while we want to validate the CURL commands generated based on the schema.

[yoavkatz]

This is a nice example that share a lot of similarity with Text to SQL. In both cases there is (1) user query (2) api/database and that target is to translate the user query to the api/database language. I think its worth looking at how the SQL was implemented: specifically:
(1) The database is defined by its unique identifier (in this case could be OpenAPI(url="https://petstore.swagger.io/v2/pets") (2) the representation of the database to the model is determined by a dedicated type serializer (in this case it could be OpenAPISpecificationSerializer(format="json") # can be yaml) (3) Metrics could also use deterministic verification like with. https://pypi.org/project/openapi-spec-validator/ that can use the OpenAPI directly to verify schema/syntax/execution

1. I wanted to keep this simple for now (I did it to show one of the users, who actually had their internal API spec representation). That's why I did not put the task in the catalog yet - and left it as a standalone example file - I felt it's not mature enough to be general.
   2.I agree a more elaborate approach could be done with a serializer for OpenAPI specs.
2. I think the above library validates the scheme (which I assume to be correct), while we want to validate the CURL commands generated based on the schema.

Given the above - you think we can merge?