17

私はこれについてしばらく疑問に思っていましたHttpResponseMessage.asp.net mvc Web APIを使用して常にWebを返す方が良いですか?

デフォルトの webapi プロジェクトをロードすると、サンプル コントローラーで使用されていないことがわかります

 // GET api/values
        public IEnumerable<string> Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET api/values/5
        public string Get(int id)
        {
            return "value";
        }

HttpResponseMessageすべてをラップして、良い Http リクエストにすると思いました。これが正しい場合、それを使用しないことの利点は何ですか?

4

2 に答える 2

18

I always return HttpResponseMessage. The point of Web API is to be able to expose an HTTP api. Pretending that you are returning an object and then relying on the framework pipeline to convert the object to a HTTPResponseMessage is just obscuring the intent IMO.

I am confident that if you pay the extra up front cost of creating the HttpResponseMessage yourself, you will understand better how Web API actually works. You will run into less problems because you are more likely to avoid Web API doing something you were not expecting. You will more likely take advantage of HTTP capabilities because the headers are right there for you to access.

于 2013-05-31T21:31:17.550 に答える
3

サービス レイヤー (クラス ライブラリ内の厳密に型指定されたメソッド) と Web サービス レイヤー (ASP.NET WEB API ) を持たない理由を分離するため。
サービス レイヤーは、Winform、WPF、コンソール、およびテスト プロジェクトで Http 依存関係なしで簡単に使用できます。また、モバイル アプリケーションや javascript などの ASPNET WebAPI によって Web サービスとして公開することもできます。
webservice Layer の問題は、HTTP の問題 (ヘッダー、コンテンツ タイプ、http ステータスなど) を使用してサービス層を公開することで、HttpResponseMessage を返すことができます。
これにより、コントローラーも非常に薄くなり、DIでサービスを注入できます

于 2013-12-09T13:58:57.797 に答える