SQLクエリをREST APIリクエストに変換する方法は？

データベースへのインターフェースを提供するREST APIの機械で読み取り可能な記述（WADL、Swagger、RAMLなど）があるとします。

私のユーザーは、基になるデータベースに関するクエリをSQLまたは同様のクエリ言語の形式で送信します。ただし、REST APIを介してのみ、データベースに直接アクセスすることはできません。

そのようなSQLクエリを特定のREST APIへの一連のリクエストに変換するシステムを（できれば記述から半自動で）構築するには、どのアプローチを選択しますか？

そのような問題をどのように表現しますか？役立つアルゴリズム、理論的フレームワーク、またはツールはありますか？

REST APIは以下をサポートします。

• 読み取り専用操作、つまりSELECTSQLクエリのみ
• XPartialプロジェクション（例/persons?fields=firstname,lastname）
• RSQL制約（別の例を/persons?query=firstname==John;department.code==42参照）。

テーブル間の一部の参照（外部キー）はREST APIでは属性として表されますが（Person.department上記の制約の例など）、一部の参照はサブリソース（例：）として表されます/persons/{userName}/projects。つまり、一部のクエリでは、RESTリクエストに関して回答される「計画」を考案する必要があります。

例：「チャックノリスのアクティブなプロジェクトの名前」のクエリは、次のように変換されます。

1. /persons?query=firstname==Chuck;lastname==Norris
2. userName結果から得る
3. /projects/{userName}?fields=name&query=state==ACTIVE

技術的には、クエリ言語はRESTサービスが理解する必要があるもう1つの標準です。クエリパラメータにマップする必要はありません。たとえば、Hydraによって、たとえばSQLを含む単一のクエリパラメータを定義することができます。必要なのは、SQLを記述できる語彙と、SQLを構築できるクライアントとSQLを理解できるサーバーだけです。この場合の一般的な語彙は、クライアントとサーバー間の契約です。これについて話す人もいます。したがって、独自のクエリ言語を作成する必要はありません。既存のクエリ言語を再利用できます...

RESTには統一されたインターフェース / HATEOAS制約があり、クライアントは状態を変更するためにハイパーリンクを使用する必要があると述べているため、WADLおよびその他のREST記述言語は不適切なスタートです。クライアントは、セマンティクスをチェックして、選択するハイパーリンクを決定する必要があります。リンクメタデータ（リンク関係など）にはそのセマンティクスが含まれています... WADLのような言語では、リンク、リンクメタデータ、またはセマンティクスはありません。したがって、RESTサービスから分離されていないため、RESTクライアントを再利用できません。：S