1

さまざまなクエリ制約をサポートする REST API を持つことのトレードオフが何であるかを知りたいです。私は、Parse のようなAPI が何をするのかという線に沿って考えています。

Parse の REST に対する考え方により、クライアント上で DB ステートメントをほぼ完全に構築することができます。サーバー上には、where: {} JSON キーを、定義されたすべての条件を含む適切な Mongo クエリに変換するエンジンがあると思います。たとえば、次のようなことができます。

curl -X GET \
  -H "X-Parse-Application-Id: xxx" \
  -H "X-Parse-REST-API-Key: xxx" \
  -G \
  --data-urlencode 'where={"hometown":{"$select":{"query":{"className":"Team","where":{"winPct":{"$gt":0.5}}},"key":"city"}}}' \
  --data-urlencode 'limit=200' \
  --data-urlencode 'skip=400' \
  https://api.parse.com/1/classes/_User

データ セクションからわかるように、この非常に柔軟なシステムを使用することで、かなり複雑で興味深いクエリをクライアントで生成できます。ここで、あなたが Parse ではなく、SQL を使用していて、(プライベート!) API の要件が、クライアントが作成できる考えられるすべてのタイプのクエリをサポートすることではないと仮定しましょう。それでも、いくつかの制約を定義できるという利点があります十分な精度でクエリを定義できないという理由だけで、クライアントが使用しないデータをクライアントに送信することを避けるためです。

上記の場合、DBステートメント生成エンジンのアプローチは単にやり過ぎですか? もしそうなら、異なるリソースがいくつかの制約 (制限、スキップ、順序付けなど) を共有するが、それらのすべてではないことに対処するより簡単な方法は何ですか? そのリソースに固有のものもあります。ここでのさまざまな設計上の決定について説明している優れたリソースはありますか?

4

1 に答える 1

1

RESTful アーキテクチャが必要な場合は、HATEOAS を使用する必要があります。つまり、以前の応答で送信された表現に基づいてクエリを生成する必要があります。したがって、 「DBステートメント生成エンジン」は不要です。設定できるすべてのオプションがサーバーによってテンプレートとして提供されるためです（たとえば、HTMLフォームですが、おそらくあなたの場合はもっと複雑なもの、おそらくカスタムコンテンツのXFormsです）タイプ）。制約は、フォーム入力マークアップによって定義されます。すべての制約をクライアントに説明するのに十分なマークアップ言語を選択してください。

于 2013-06-10T10:37:25.950 に答える