RESTは捨てるのではなくApplication CoreからAdapterへ降格させる
Applicationが中規模化しMCPやJobを持つようになっても、RESTを捨てる必要はない。問題はRESTを「Applicationそのものの構造」とみなすことにある。RESTを 外部公開用のAdapter と位置付け直せば、既存のHTTP APIの利点を保ったまま他Transportと共存できる。
Google AIPのResource-oriented designは、ResourceとMethodを一貫したHTTP APIへ写像する強力な設計規約である。特に標準Methodとcustom methodの規則は、人間向けAPI・SDK・CLI生成に有用であり続ける。一方、GoaのようにService MethodとHTTP mappingを分ければ、そのREST surfaceをApplication Operationの外側へ配置できる。
REST API ─┐
MCP ─┼→ Application Operation
Job ─┘
この配置では、RESTのResource pathは依然として重要だが、Module ownershipや認可境界を必ずしもpath treeから導出しなくてよい。HTTP route変更がApplication Coreの再編を強制しにくくなる点も大きい。
反対に、TransportがHTTPしかなく、CRUD中心で、routeとuse caseがほぼ一対一なら、この分離は抽象化コストを増やすだけかもしれない。小規模な段階ではroute handlerをそのままApplication Operationとして扱い、複数Transportや複雑な認可が現れた時点で境界を明示する方が合理的なこともある。
Router ResponsibilityはResource Resolutionや業務認可まで抱え込まない方が拡張しやすい と Transport AdapterはHTTPやMCPをApplication Operationへ翻訳する境界 が、この「RESTは残すが責務を狭める」方針を補う。