OAS -> Function-Calling

[doyu]

Validate the automated conversion from OAS to Function Calling via OpenAI API

Task List

• [x] Create Minimal OpenAPI Specification (OAS)

  • Define a simple OAS file with a single /hello endpoint.
  • Configure the endpoint to accept an optional name query parameter and return a JSON greeting message.

• [x] Implement Simple Web Server

  • Set up a basic FastAPI server based on the OAS specification.
  • Define the /hello endpoint to handle the name parameter and return a dynamic greeting message.

• [x] Run and Test Web Server

  • Save the FastAPI code (e.g., as main.py).
  • Launch the server with uvicorn, ensuring it serves at http://127.0.0.1:8000.
  • Verify the OpenAPI spec is accessible at http://127.0.0.1:8000/docs.

• [x] Validate GPT-4O OAS Conversion

  • Upload the OAS file to a compatible interface with GPT-4O.
  • Test GPT-4O’s ability to call the /hello endpoint:
    • Without a query parameter (should return "Hello, World!").
    • With a name parameter (should return a personalized greeting).
  • Confirm that GPT-4O interprets and generates function calls according to the OAS specification.

• [x] Document Results and Findings

  • Record whether GPT-4O successfully converted the OAS file into function-calling capabilities.
  • Note any issues, improvements, or limitations encountered.

• [ ] #29

  ---

  References

  There are sample OAS & fastAPI code listed below.

• https://chatgpt.com/share/6720630a-827c-8002-85f7-6f02eff3d382

[linhktran]

An openapi.json file is automatically generated when a web is created and I have a function to extract the necessary information from OAS to be compatible with Function Calling. FC can also be made automated with further investigation.

[doyu]

Digitraffic provides OAS. Can we automatically convert into FC? Requested by FVH today.

[linhktran]

I would say it is possible because OAS has quite some necessary information to pass in a tools list.

[doyu]

Can you play with the above Digitraffic OAS on chatGPT and see if we could easily play with it via natural language? This should be another backlog item.

[doyu]

How does this OAS->FC conversion work?

Does this work as below?

1. OAS -> Python function (Fn)
2. Fn -> FC

Is this my understanding right? If so, for the part of the above 2, 06_class_to_fc.ipynb can be used after the above 1? 06_class_to_fc.ipynb needs some more modification to accept any functions, though.

Then, please use class_to_fc (actually, fn_to_fc, though) in 04_oas_to_fc.ipynb

Does the above make sense?

04_oas_to_fc.ipynb --renamed--> 04_oas_to_fn.ipynb

[doyu]

Once 04_oas_to_fc.ipynb can work with any OAS basically, please try Digitraffic OAS which FVH is interested to see how it's easy or difficult. I'll put this on our backlog item in the description.

[nghivo94]

Here are some summary and information about the Open Spec file that can be useful in constructing a function, which I am using in my testing with OAS -> fastAPI

Some important attributes of this Open Spec file include:

• openapi: Specifies the version of the OpenAPI Specification being used (e.g., 3.0.0 or 3.1.0).
• info: Contains metadata about the API. Common Fields:
  • title: The title of the API.
  • description: A brief description of the API.
  • version: The version of the API (not the OAS version).
  • termsOfService: URL to the terms of service.
  • contact: Contact information for the API.
  • license: License information for the API.
• servers: Lists the server URLs where the API is available. Common Fields:
  • url: The URL of the server.
  • description: Description of the server environment (e.g., production, development).
• paths: Describes the available API endpoints and their operations. Each key in paths represents an endpoint (e.g., /users, /items/{itemId}). Common Fields per Path:
  • HTTP methods (get, post, put, delete, etc.): Each method contains details about the operation in a nested format:
  • summary: A brief summary of the operation.
  • description: A detailed description of the operation.
  • operationId: A unique identifier of the operation.
  • parameters: Describes the input parameters for the operation.
  • requestBody: Defines the body of a request (for post, put, etc.).
  • responses: Describes the possible responses, with HTTP status codes and content.
• components: Houses reusable components for the API, which can be referenced elsewhere in the document. Sections:
  • schemas: Reusable data models, typically defining request/response structures.
  • parameters: Predefined parameters to reuse across multiple endpoints.
  • requestBodies: Reusable request body definitions.
  • securitySchemes: Defines security protocols (e.g., API keys, OAuth2).

And for each endpoint, I am extracting hese attributes:

[nghivo94]

Furthermore, regarding the inputs and outputs of an endpoint, here is a rough summary of different types of inputs and outputs:

Inputs

• Request body: usually JSON (unless uploading files or forms), defined as a schema in components and referred to in the endpoint, e.g., Reference in endpoint:

Definition in component

• Query parameter: simple inputs to attach to URL, e.g., endpoint?query1=... or using requests library in Python. Defined directly in endpoint:

• Path parameters: simple inputs directly defined in URL, e.g., accounts/{user_id}. Defined directly in endpoint:

Outputs

• Status codes: single number representing the status of requests. Successful requests will have status codes starting with 2..., e.g., 200 (retrieving information successfully), 204 (operation success but no further outputs). User-side errors will have status codes starting with 4..., e.g., 400 (bad request), 404 (not found), 401 (unauthorized). Any kind of unrecognized error will usually result in 500 (internal server error).
• Description: simple description of responses (e.g., when the response occurs)
• Response body: outputs, usually in JSON (unless returning files), defined similarly to request body in components and referred to in endpoint definition.

[doyu]

Here are some summary and information about the Open Spec file that can be useful in constructing a function, which I am using in my testing with OAS -> fastAPI

Look like there should be some common component to be used "OAS->Fn" since "OAS->fastHTML" can be implemented on the top of "OAS->Fn". @nghivo94 Where can we take a look at the implementation? @linhktran Probably you can factor out some of the features from there?