refactor(platform/rest): Update REST API to use standard FastAPI structure

[Swiftyos]

Background

The rest FastAPI server is currently packaged up and ran from within a separate process. This has resulted in needing to develop the FastAPI server in a unique way, preventing us from leveraging some of its features and slightly increasing the difficulty of adding new routes.

Work has been done to decouple the Rest server from the executors. This is the follow on work to refactor the API server to a canonical FastAPI setup.

Changes 🏗️

• Moved to a standard FastAPI server, ran via uvicorn directly, in the docker container.

• Ensured openapi schemas matched exactly:

  Added python script to ensure openapi specs do not change during refactor

   % python comp.py                                     
  The two OpenAPI specifications are identical.
  

• Moved endpoints from /api/x to /api/v1/x

Testing 🔍

Note

Only for the new autogpt platform, currently in autogpt_platform/

• Create from scratch and execute an agent with at least 3 blocks
• Import an agent from file upload, and confirm it executes correctly
• Upload agent to marketplace
• Import an agent from marketplace and confirm it executes correctly
• Edit an agent from monitor, and confirm it executes correctly

Configuration Changes 📝

Note

Only for the new autogpt platform, currently in autogpt_platform/

If you're making configuration or infrastructure changes, please remember to check you've updated the related infrastructure code in the autogpt_platform/infra folder.

Examples of such changes might include:

• Changing ports
• Adding new services that need to communicate with each other
• Secrets or environment variable changes
• New or infrastructure changes such as databases

[github-actions]

This PR targets the master branch but does not come from dev or a hotfix/* branch.

Automatically setting the base branch to dev.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 No relevant tests

🔒 Security concerns CORS configuration: The CORS middleware in autogpt_platform/backend/backend/server/routers/v1.py is configured to allow all origins, methods, and headers. This could potentially lead to security vulnerabilities if not properly restricted in production. It's recommended to specify allowed origins, methods, and headers explicitly rather than using wildcard "*" for all.

⚡ Recommended focus areas for review Error Handling The global exception handler might be too broad. It catches all exceptions and returns a 500 status code, which could mask specific errors that should be handled differently. Security Concern The CORS middleware is configured to allow all origins, methods, and headers. This could potentially lead to security vulnerabilities if not properly restricted in production. Error Handling The error handling in the execute_graph function could be improved. It's catching all exceptions and returning a 400 status code, which might not be appropriate for all types of errors.

[netlify]

✅ Deploy Preview for auto-gpt-docs canceled.

Name	Link
🔨 Latest commit	69fcf2f
🔍 Latest deploy log	https://app.netlify.com/sites/auto-gpt-docs/deploys/6724c5131b1c07000841043b

[majdyz]

codewise LGTM,
I have no opinion on v1 routing, is this something that we want to do?
Should we not retain the default one to point to the latest version to maintain backward compatibility?