在实现REST端点以用于运营时，插入了GraphQL端点时所做的是正确的。

? 这个处理方式尚未投入生产，可能会出现更好的方法或需要考虑其他事项 ?
? 这仅仅是针对共存的讨论 ?

之所以需要考虑共存问题是因为 REST 端点和 GraphQL 端点在处理异常响应时的规范不同。（以下的处理是基于 REST 规范或特定使用方式的 FastAPI 功能，因此仅在这种情况下发生，请知悉。）

调整 OAuth2AuthorizationCodeBearer 来进行 Bearer Token 的检查。

只需要一种选项：如果 OAuth2AuthorizationCodeBearer 在 Bearer Token 上有任何问题时，框架会代替抛出 401 错误，并且需要分别在对 REST 请求和 GraphQL 请求的响应中进行实现。

将以Router Level为基础的处理使用depends进行检查，为GraphQL准备。

在仅使用 REST 时，如果通过检查处理引发了异常，我们使用 exception_handlers 拦截并返回 HTTP 响应。当添加了 GraphQL 后，由于检查处理没有成为一个具有判定请求来源的材料的接口，所以我们使用 depends 进行检查的处理被准备为适用于 GraphQL。 （由于规模较小，我们判断这比扩展接口更好）。

不需要多说了。

印象

在推进过程中，我意识到FastAPI在许多繁琐的事情上替我分担了很多，这是一个很好的机会。

广告

非常感谢您读到最后。

最近，我成功地提交了 Strawberry GraphQL。对于那些使用 Strawberry GraphQL 的人们，请多多关注和支持。

PR合并的文化圈与完全不同的人交流让我非常紧张。虽然只是加入了一个例外，但这是一次很好的经验。

另外，我们公司正在积极使用另一款产品。期待大家的申请！访问链接https://www.wantedly.com/projects/1181162