django - 違い - ubuntu python grpc



RESTとRPCを混在させることは悪い習慣ですか? (1)

私はREST Webサービスにはかなり新しく、 RPCに非常に慣れています。 私はこのようないくつかの記事を読むことでRESTの利点を知っています。

私はdjango-rest-frameworkを使ってdjangoでサーバーを開発しています。

この質問(または質問)はありますが:

私はこのモデルを持っています:

class Poll(models.Model):
    questionString = models.CharField(max_length=500, blank=True)
    timeToAnswer = models.IntegerField(default=30)
    startDate = models.DateTimeField(null=True, db_column='startDate', blank=True)
    token = models.CharField(max_length=20, blank=True, unique=True)

class PollAggregator(models.Model):

    name = models.CharField(max_length=135)
    description = models.CharField(max_length=500, blank=True)
    votersToken = models.CharField(max_length=20, null=True, blank=True)

class PollPollAggregatorRel(models.Model):
    pollAggregator = models.ForeignKey(PollAggregator, null=True, db_column='pollAggregatorId', blank=True)
    poll = models.ForeignKey(Poll, null=True, db_column='pollId', blank=True)

だから私は1つの投票をすることができますか、私は投票集計(つまり部屋)で集計された投票の束を持つことができます。

だから私は残りの呼び出しを作成しました:pollList、pollDetail、pollAggregatorList、pollAggregatorDetail。 しかし、私はPollPollAgregatorRelの設計に問題があります。 もちろん、私はPollPollAgregatorRelListとPollPollAgregatorRelDetailを持ち、通常の投稿、取得、更新、削除を行うことができます。 したがって、RESTスタイルの投票集計と投票集計の間に新しい関係を作りたい場合は、次のようにします。

  • pollPollAgregator(list)が、ポーリングIDとgetを持ち、pollIdによってフィルタリングされているかどうかを確認します。
  • もしそうなら、私はこのアイテムを更新して、私の新しいpollAggregator id
  • そうでない場合は、ポストを持つ新しいPollPollAgregatorを作成します

私の最初の質問は、これを行うための簡単で簡単な方法がありますか?

私がWebサービスのようなRPCを使うと、私は次のようなことをします:

  • pollAggregatorとポーリングを関連させ、PollPollAggregatorRelにget_or_createを使用します。 そこで私は新しいPollPollAggregatorRelオブジェクトを更新または作成します。

したがって、RPCのようなものを使用すると、クライアントは1回の呼び出しと2回の呼び出しが必要なRESTを使用します。 この場合、サーバー側とクライアント側の両方でRPCを使用する方がずっと簡単です。

2番目の質問は、同じAPIでRESTとRPCの両方を使用することは悪い習慣ですか?


Q1:既存のアグリゲーターを返すか、必要に応じて新しいアグリゲーターを作成するRESTスタイルのPOST操作を提供することは合理的だと思います。 論理的には、あなたの "RPC"サービスと違わないようです。

あなたの難しさの一部は、あなたのRESTの "呼び出し"(ヒント:彼らは "呼び出し"ではなく、彼らは "リソース")を設計しているかもしれないと思うかもしれません。 私が過去にした間違いです。

REST!= CRUD。

RESTの主な利点は、インタフェースをモデルから分離できるため、サーバーはクライアントに影響を与えずに実装を変更できることです。 もう1つの重要な利点は、クライアントが事前に何らかの操作を実行するために知っておく必要がある情報の量を最小限に抑えることです。 例えば、RESTクライアントは、サービスの "フロントリソース"( "フロントページ"との類推によって)と対話することによって、使用する必要があるすべてのリソースURIを発見できるはずです。

だから私はあなたが上記で説明したものをカバーする以下のリソースがあるアプローチを考えます:

  1. その表現が他のリソースへのリンク(またはリンクテンプレート)を含む(またはHTTPリンクヘッダを介してリンクを返す)サービスホームページ。

  2. (例えば、GETはすべてのポーリングのリストを返し、POSTは新しいポーリングを作成します)

  3. 個々の世論調査では、「投票集計」とのやりとりを通じてURIが検出されます。 GET、PUT、DELETEはあなたが期待するように行います。 私はあなたがこれらのためのPOSTが必要かどうか分からない。

  4. ポーリングを集約に関連付ける「集計マネージャ」リソース(ポーリングは複数の集約に属しますか?あなたの説明は示唆しません)。 POLL URIを含むこのリソースへのPOSTは、集約(または集約)を検索または作成したり、新しいものを作成したりする可能性があります。 GETは既存の集約のリストを返すかもしれません。

  5. アグリゲーションマネージャリソースとのやりとりを通じてURIが検出される個々のアグリゲーションリソース

あなたの説明では、PollPollAggregatorRelはあなたの(現在の)実装の一部であり、REST APIを通してそのように公開するものではありません。 これにより、クライアントのAPIの使用方法に影響を与えずに、内部実装を柔軟に変更できます。 それがRESTのポイントです。

私はあなたがこれを「より簡単でシンプル」と考えるかどうかは分かりませんが、それはRESTのポイントではありません。 RESTはRoy Fieldingによって「数十年にわたるソフトウェアエンジニアリング」として記述されており、ウェブスケールで動作するアプリケーションにとって重要な、クライアントとサーバーの実装の比較的独立した進化を可能にするインタフェースを作成することがポイントです。 これを支払う代価があります。これは、クライアントがサーバーと対話して、相互作用を進めるために必要な情報を発見しなければならないということです。

Q2: 同じAPIで RESTとRPCを混在させるのは賢明ではないと思います 。 (RESTを外部のクライアントに公開し、内部的にRPCを使用したり、別個のAPIを提供することは理にかなっています。

私の根拠は、ほとんどのREST APIを持っていれば、RPC要素を追加すると、クライアントとサーバーの間に緊密な結合が作成され、最初はRESTを使用する点を否定することになります。





django-rest-framework