1

私は Web Api を使用しており、クライアントがn秒ごとにハートビート通知を送信しているシナリオがあります。PUT ではなく POST で送信されるハートビート オブジェクトがあります。これは、既存のハートビートを更新するのではなく、新しいハートビートを作成しているためです。

さらに、クライアントには、現在オンラインになっている他のすべてのクライアントと、個々のクライアントが持つ未読メッセージの数を取得する必要があるという要件があります。私には2つのオプションがあるようです：

  1. POST に続いて GET を実行します。これは、純粋な REST の観点からはよりクリーンに思えます。私は作成と検索を行っていますが、SOLID の原則は、それに応じてそれらを分割することを好むと思います。ただし、このアプローチは 2 回の往復を意味します。
  2. GET がそうでなければ行ったのと同じ情報を含むオブジェクトを POST に返させます。これにより、すべてが 1 つの要求に統合されますが、このアプローチは賢明ではないと考えられるのではないかと懸念しています。純粋な POST ではありません。

オプション #2 のスタブは次のようになります。

public HeartbeatEcho Post(Heartbeat heartbeat)
    {
    }

HeartbeatEcho は、他のオンライン クライアントのプロパティと未読メッセージの数を含むクラスです。

Web Api は確かにオプション #2 をサポートしていますが、何かを実行できるからといって、実行する必要があるとは限りません。オプション #2 は忌まわしいもの、時期尚早の最適化、またはプラグマティズムですか?

4

2 に答える 2

6

オプション2はまったく忌まわしいものではありません。POSTリクエストは新しいリソースを作成しますが、リソース自体が呼び出し元に返されることは非常に一般的です。たとえば、リソースがデータベース内のアイテム（Personなど）である場合、POSTリクエストはINSERT操作に必要なメンバー（名前、年齢、住所など）を送信し、応答にはPersonオブジェクトが含まれます。入力として渡されるパラメーターに加えて、オブジェクトを一意に識別するために使用できる識別子（DB主キー）もあります。

新しく作成されたリソースのIDのみを返すPOSTリクエストに対しても完全に有効であることに注意してください。ただし、クライアントの要件に応じて、これを選択できます。

public HttpResponseMessage Post(Person p)
{
    var id = InsertPersonInDBAndReturnId(p);
    p.Id = id;
    var result = this.Request.CreateResponse(HttpStatusCode.Created, p);
    result.Headers.Location = new Uri("the location for the newly created resource");
    return result;
}
于 2012-07-14T03:50:21.313 に答える
3

ビジネス上の問題を解決する方法はどれでもうまくいきます。新しいレコードの POST と既存のレコードへの更新の PUT は正しいです。

提案: 考慮すべきことの 1 つは、Redis をスタックに追加することです。アプリは非常に高速に投稿できます。その後、エコー部分または Blpop (レコードが条件に一致するまでブロック) に Pub/Sub 機能を使用できます。これは非常に高速で、スケーリングに役立ち、目的に合わせて完全に設計されています。

参照: http://redis.io/topics/pubsub/

参照: http://redis.io/commands/blpop

私は両方のRedisを同様に使用しましたが、RabbitMQも使用しました。RabbitMQを使用して、長いポーリングを必要とせずにリアルタイムでハートビートを「ストリーミング」するためにsocket.io接続を追加しました。

于 2012-07-14T03:46:28.283 に答える