3

私の最初の WCF rest プロジェクトを開始したばかりで、REST を使用するためのベスト プラクティスについてのヘルプが必要です。

私はいくつかのチュートリアルを見てきましたが、物事を行うにはいくつかの方法があるようです...たとえば、POST を実行する場合、HttpStatusCodes (OK/Errors など) を設定しているいくつかのチュートリアルと、それらが設定されている他のチュートリアルを見てきました。操作の結果を含む文字列を返すだけです。

結局のところ、4 つの操作があり、GET を実行している場合はこのように実行し、POST を使用している場合はこれを実行するように指示するガイドが必ずあるはずです...

どんな助けでも大歓迎です。

JD

4

3 に答える 3

6

更新

ASP.NET Web API を使用します。

OKコメントを残しましたREST best practices: dont use WCF REST. Just avoid it like a plagueが、説明しなければならないと感じています。

WCF の根本的な欠陥の 1 つは、それがPayloadのみに関係していることです。たとえば、FooとBarはペイロードです。

[OperationContract]
public Foo Do(Bar bar)
{
    ...
}

これは WCF のテナントの 1 つであるため、トランスポートが何であれ、ペイロードが渡されます。

しかし、それが無視するのは、context/envelope多くの場合トランスポート固有の呼び出しです。そのため、多くのコンテキストが失われます。実際、HTTP の力はペイロードではなくコンテキストにあり、以前のバージョンの WCF では、クライアントの IP アドレスを取得する方法がなくnetTcpBinding、WCF チームはそれを提供できないと断言していました。私は今ページを見つけることができませんが、コメントを読んだことを覚えています.MSの担当者は、これはサポートされていないと言いました.

WCF REST を使用すると、次の点で HTTP の柔軟性が失われ、自分自身を明確に表現できなくなります (後で修正する必要がありました)。

  • HTTP ステータス コード
  • HTTP メディア タイプ
  • Eタグ、...

新しい Web API である Glenn Block が機能しており、ペイロードをコンテキストにカプセル化することで、この問題に対処しています。

public HttpResponse<Foo> Do(HttpRequest<Bar> bar) // PSEUDOCODE
{
    ...
}

しかし、私のテストではこれは完璧ではなく、個人的には Nancy などのフレームワークやプレーンな ASP NET MVC を使用して Web API を公開することを好みます。

于 2012-01-30T12:31:02.210 に答える
6

HTTP 仕様に由来するさまざまな HTTP 動詞を使用する場合、いくつかの基本的な規則があります。

GET: これは純粋な読み取り操作です。呼び出しによってサービスの状態が変化してはなりません。GET への応答は、キャッシュ ヘッダーに応じてキャッシュ (ローカル、プロキシなど) から配信される場合があります。

DELETE: リソースの削除に使用

PUT と POST について混乱することがあります - どちらをいつ使用する必要がありますか? 冪等性を考慮する必要があることに答えるには、サービスの状態に影響を与えずに操作を繰り返すことができるかどうか - たとえば、顧客の名前を値に設定すると、状態をさらに変更することなく複数回繰り返すことができます。ただし、顧客の銀行残高を増やしている場合、サービスの状態をさらに変更しない限り、これを安全に繰り返すことはできません。最初のものはべき等であると言われていますが、2番目のものはそうではありません

PUT: 冪等の非削除状態変更

POST: 冪等でない非削除状態の変更

REST は HTTP を採用しているため、失敗は HTTP ステータス コードを使用して通知する必要があります。成功の場合は 200、作成の場合は 201、サービスは HTTP ロケーション ヘッダーを使用して新しいリソースの URI を返す必要があります。 5xx は、サーバー側でのみ解決できるサーバー エラーです。

于 2012-01-30T12:32:01.583 に答える
0

There's something missing here that needs to be said.

WCF Rest may not be able to provide all functionality of REST protocol, but it is able to facilitate REST protocol for existing WCF services. So if you decide to provide some sort of REST support on top of the current SOAP/Named pipe protocol, it's the way to go if the ROI is low.

Hand rolling full blown REST protocol maybe ideal, but not always economical. In 90% of my projects, REST api is an afterthought. Wcf comes in quite handy in that regard.

于 2012-07-24T04:12:27.180 に答える