【要約】【RFC 10008】新HTTPメソッド QUERY 入門 — GETのかゆいところに手が届く / FastAPIで動くのか実際に試した [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
API開発者は、複雑な検索条件を持つAPIを設計する際、既存のGETやPOSTの制約に直面している。具体的には以下の課題がある。
- ・GETではURL長制限に抵触し、ネストしたJSON構造の表現も困難である。
- ・GETにボディを付ける行為は、中間装置で破棄される等の仕様上の不安定さがある。
- ・検索条件がURLに含まれるため、アクセスログ等から機密情報が漏洩するリスクがある。
- ・POSTでは、キャッシュや自動リトライが困難であり、読み書きの判別もできない。
// Approach
開発者は、GETの性質を保ちつつボディを利用できる「QUERY」を採用することで、これらの課題を解決する。具体的な手法は以下の通りだ。
- ・FastAPIでは
@app.api_route(methods=['QUERY'])を用いてルーティングを行う。 - ・OpenAPIにボディを出力させるため、内部定数へのモンキーパッチを適用する。
- ・キャッシュ実装時は、JSONの正規化を行い、意味的に同一なリクエストを識別する。
- ・初回はQUERYで受け、以降は
Locationヘッダを用いてGETへ誘導する設計をとる。
// Result
QUERYメソッドの導入により、検索APIの設計における整合性と実装の容易性が向上する。
- ・URL長制限や構造化データの扱いに悩むことなく、型安全な実装が可能になる。
- ・FastAPIにおけるOpenAPI生成の不備に対する、具体的な回避策が示された。
- ・「初回はQUERY、以降はGET」という設計により、未対応のCDN環境下でもキャッシュの恩恵を受けられる道筋が明確になった。
Senior Engineer Insight
> 検索APIにおけるPOSTの多用は、意味論的な欠陥を抱えていた。QUERYはこれを正しく解決する。ただし、インフラの対応が遅れている現状では、キャッシュ性能のみを期待した導入は時期尚早だ。実戦では、まず「意味論の整理」と「ログへの機密情報混入防止」を主目的とし、既存のPOSTと併用しながら、段階的にGETへ逃がす設計を組み込むべきである。