タグ付けされた質問 「web-api」

現時点では、ユニットテストを許可するようにコード設計を変更することはコードのにおいであるのか、それともコードのにおいをせずにどの程度できるのかについて、チームで議論が行われています。これは、他のすべてのソフトウェア開発会社に存在するプラクティスを導入し始めたばかりだからです。 具体的には、非常に薄いWeb APIサービスが用意されます。その主な責任は、Web要求/応答をマーシャリングし、ビジネスロジックを含む基盤となるAPIを呼び出すことです。 1つの例は、認証方法の種類を返すファクトリの作成を計画していることです。インターフェースを継承する必要はありません。具体的なタイプ以外のものになるとは思わないからです。ただし、Web APIサービスを単体テストするには、このファクトリをモックする必要があります。 これは本質的に、（コンストラクターまたはセッターを介して）DIを受け入れるようにWeb APIコントローラークラスを設計することを意味します。つまり、DIを許可するためだけにコントローラーの一部を設計し、そうでなければ必要のないインターフェースを実装することを意味しますこの方法でコントローラーを設計する必要を避けるために、Ninjectのようなサードパーティのフレームワークがありますが、インターフェイスを作成する必要があります。 チームの何人かは、テストのためだけにコードを設計することを渋っているようです。単体テストを行うには妥協が必要だと思われますが、彼らの懸念をどのように和らげるかはわかりません。 明確にするために、これはまったく新しいプロジェクトであるため、コードを変更して単体テストを有効にすることではありません。ユニットテスト可能になるように記述するコードを設計することです。

91 unit-testing  interfaces  web-api  asp.net-core 

私は現在15人の開発者から成るチームを管理していますが、WCFとWeb APIの使用について議論している2つの完全に反対のチームに分かれる技術を選択する段階で立ち往生しています。 Web APIの使用をサポートするチームAは、次の理由を提示します。 Web APIは、サービスを記述するための単なる最新の方法です（ウィキペディア） WCFはHTTPのオーバーヘッドです。TCP、Net Pipes、およびその他のプロトコルのソリューションです [DataContract]＆[DataMember]およびそれらの属性のため、WCFモデルはPOCOではありません SOAPはJSONほど読みやすくて便利ではありません SOAPは、JSON（HTTPを介したトランスポート）と比較してネットワークのオーバーヘッドです メソッドのオーバーロードなし WCFの使用をサポートするチームBは次のように述べています。 WCFは複数のプロトコルをサポートします（構成を介して） WCFは分散トランザクションをサポートします WCFには多くの良い例と成功事例があります（Web APIはまだ若いです） デュプレックスは双方向通信に最適です この議論は継続しており、今何をすべきかわかりません。個人的には、正しい使用場所にのみツールを使用すべきだと思います。言い換えれば、HTTP経由でサービスを公開したいが、TCPとDuplexの場合はWCFを使用する場合は、Web APIを使用した方がよいでしょう。 インターネットを検索しても、確実な結果を得ることができません。WCFをサポートするための多くの投稿がありますが、それどころか、人々がそれについて不満を持っていることもわかります。この質問の性質は議論の余地があるように聞こえるかもしれませんが、決定するにはいくつかの良いヒントが必要です。偶然テクノロジーを選択すると、後悔する可能性があります。目を開いて選びたい。 私たちの使用は主にWebのためであり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合があります。 私は今どうすればいい？この議論を建設的な方法で管理するにはどうすればよいですか？

49 wcf  decisions  web-api 

私はこれについて疑問に思っていました。 フィールドとフィールドを持つuserリソースがあるidとしnameます。フィールドを更新したい場合は、次のようにリソースに対してPATCHリクエストを行うことができます。 PATCH /users/42 {"name": "john doe"} そして、アプリケーションはユーザー42の名前を更新します。 しかし、なぜこのリクエストを繰り返した場合、結果が異なるのでしょうか？ よると、RFC 5789 PATCHは安全でもi等でもありません

48 rest  api-design  http  web-api 

私は以前SignalR、いくつかのプロジェクトでリアルタイムのメッセージング機能を実現していました。確実に機能するようで、使い方を学ぶのは非常に簡単です。 少なくとも私にとっての誘惑は、Web APIサービスの開発を放棄し、SignalRすべてに使用することです。 思いやりのある設計によってこれを達成できると思います。もしそうなら、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなく、サービスへの単一のインターフェースがあることを意味し、最悪の場合、物事がいつレンダリングされるかなどを考えずにこれを接続できることを意味します。 だから、私は知りたい： パフォーマンス以外にすべてのWebサービスの代わりにSignalRを使用しない他の理由はありますか？ SignalRのパフォーマンスは、そうするのが理にかなわないということに関して十分ですか？ 馬鹿げたようなことをせずに、サーバー側のオブジェクトとサービスの定義をクライアント側のサービスアクセスコードに変換できることは、長い間私の夢でしたnode.js。たとえば、興味深いオブジェクトInterestingObjectとそのオブジェクトへのサービスを定義する場合、サービスへCRUDのInterestingObjectService標準のURLルートを定義できます-"/ {serviceName} / {methodName}"-しかし、アクセスするクライアントコードを記述する必要がありますサービス。オブジェクトは、サーバーとバックにクライアントから渡されようとしているので、する実際的な理由はありません持っているがクライアント側のコードでオブジェクトを明示的に定義します。また、CRUD操作を実行するルートを明示的に定義する必要はありません。このすべてを標準化する方法があるはずだと思うので、WinFormsまたはJavaを書いている場合と同じように、サービスへのアクセスがクライアントからサーバーへ、そして透過的に戻るという仮定の下でクライアントを書くことが可能ですアプレットまたはネイティブアプリ、またはあなたが持っているもの。 SignalRが従来のWebサービスの代わりに使用するのに十分であれば、これを実現するための実行可能な方法である可能性があります。SignalRには、既に説明したサービスのようにハブを機能させる機能が既に含まれているため、この機能すべてをすぐに反映できる共通ベース（CRUD）サービスを定義できます。そうすれば、ほとんどの場合、サービスへのアクセスを許可することができ、慣習によってアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます。 DOM。 私の編集を読んだ後、私はそれが少し無意味であるように感じるので、私が何を得ているかについて質問があるかどうか私に尋ねてください。基本的に、サービスへのアクセスは可能な限り透過的にする必要があります。

42 design-patterns  rest  web-api  websockets 

したがって、私は.Net WebApiを使い始めたばかりで、すぐに気づいたことの1つは、APIの外観と消費方法（各アクションからのリクエスト/レスポンス）を定義する契約がないことです。これは通常の形式ですWCF / SoapのWSDL。 これは非常に価値があり、APIの利用者の生活をずっと楽にするものであるように思えます。 存在しない理由はありますか？知らないプログラミングのパラダイムや原則はありますか？作成する方法はありますか？

33 c#  asp.net-mvc  web-api 

私はモバイルアプリケーションを持つMVCのプロジェクトに取り組んでいるので、モバイルアプリケーションで使用できるようにWeb APIを使用する必要があることは明らかです。 Webサイトの開発を開始したときにAPIを作成した後、私たちは混乱し、APIを使用するか、ビジネスオブジェクトに直接アクセスするかについて議論しました。そして、ビジネスオブジェクトを直接使用する代わりに、Web APIを使用する経験豊富な開発者の意見を聞いた後、私たちは終わりました。 このソリューション構造に関して混乱が生じています。 1）Web APIを使用し、HTTP要求（時間のかかる）を行って、同じソリューションにあるビジネスオブジェクトの代わりにデータを直接取得または配置する必要がある理由。 2）引数を取得した後、クライアントが別のクラウドサーバーでAPIとWebをホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合（論理的）その場合、同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか？ 3）APIとWebを異なるホスティングでホストしている場合、WebはWebClientを使用し、各ナビゲーションでHTTP呼び出しを行います。正しいですか？ 4）別のサーバーでAPIとWebホスティングの両方からビジネスオブジェクトを作成する場合、BLで何か変更を加えた場合は、両方のサーバーでビルドを更新する必要があります。 5）または、API用のプロジェクトを1つだけ作成し、ビューまたはhtmlページを追加してWebインターフェースを開発することで、ajaxから直接APIを呼び出すことができます。 私の知る限りでは、＃5が最適なソリューションであるか、APIはサードパーティアクセス専用です。同じソリューションにDB、EF、データ層、ビジネス層がある場合、APIを使用してHTTP呼び出しを行ったり、ビジネスオブジェクトに直接アクセスしたりしないでください。（間違っている場合は修正してください）APIは、モバイルアプリケーションやデスクトップ、またはアプリケーションにアクセスしたいときに同じリポジトリとデータレイヤーを持つために必要です。 私のシナリオでは、モバイルアプリケーションもあるため、APIを作成する必要があります。プロジェクトAPI側では、ビジネスレイヤー（別のプロジェクト）と呼ばれ、ビジネスレイヤーはデータアクセスレイヤー（別のプロジェクト）と通信します。したがって、私の質問は、APIとWebを異なるサーバーにホストする場合、プロジェクトを作成してビジネスレイヤーの.dllを作成するときに、ビジネスレイヤーのメソッドを使用するよりも、HTTPリクエストであるAPIの呼び出しに時間がかかる場合があります APIコントローラーでは、ビジネスの出力をJSON形式に変換するだけです。 インターネットで検索しましたが、納得のいく答えが得られませんでした。私はブログ見つけたhttp://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspxを同じポイントを議論したが、再びそのブログで私の質問は、シナリオ＃3を検討する必要がある理由です。 更新：異なるAPIプロジェクトとMVCプロジェクトを使用でき、jvascriptを使用してWebからAPIを呼び出すか、MVVMパターンを使用できます。

33 project-structure  asp.net-mvc-4  web-api  asp.net-mvc-web-api 

2つのクラスがある： public class Parent { public int Id { get; set; } public int ChildId { get; set; } } public class Child { ... } 割り当てるときChildIdにParent、それが例外をスローするDB用DBまたは待機中に存在する場合、私が最初に確認する必要がありますか？ 例（Entity Framework Coreを使用）： 注：これらの種類のチェックは、Microsoftの公式ドキュメントでもインターネット全体で行われます：https : //docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- mvc / handling-concurrency-with-the-entity-framework-in-an-asp-mvc-application＃modify-the-department-controllerしかし、追加の例外処理がありますSaveChanges また、このチェックの主な目的は、APIのユーザーにわかりやすいメッセージと既知のHTTPステータスを返すことであり、データベースの例外を完全に無視することではないことに注意してください。そして、例外がスローされる唯一の場所は、内部にあるSaveChangesかSaveChangesAsyncを呼び出すときに例外がありません...コールFindAsyncまたはAny。そのため、子が存在するが以前に削除されていた場合SaveChangesAsync、同時実行例外がスローされます。 これは、foreign key violation「ID {parent.ChildId}の子が見つかりませんでした」と表示するために、例外の書式設定がはるかに困難になるという事実のために行いました。 public async Task<ActionResult<Parent>> CreateParent(Parent parent) { // is this …

32 c#  entity-framework  orm  web-api  asp.net-core 

過去2つの会社では、Webアプリを介してデータを照会するためにREST APIを使用していました。すなわち。Webアプリに直接SQLを実行させる代わりに、REST APIを呼び出し、SQLを実行して結果を返します。 私の質問は...なぜこれが行われるのですか？ 第三者にさらされるとしたら、理解できました。完全なDBよりも制限されたREST APIを公開する方が適切です。しかし、これらの企業の両方ではそうではありません。 これらのREST APIを使用すると、DBMSを簡単に切り替えることができるようになりました。しかし、それはデータベース抽象化レイヤー（DBAL）のポイントではありませんか？ORMをDBALとして使用するか、生のSQLを記述し、必要に応じてDBALにDB固有のものを変換させることができます（たとえば、MySQLのLIMITをMSSQLのTOPに変換します）。 いずれにせよ、それは私には不要のようです。また、問題の診断も難しくなると思います。Webアプリのレポートが間違った数値を提供している場合、SQLクエリをダンプすることはできません。RESTURLをダンプしてから、REST APIとして機能するプロジェクトに移動して、そこからSQLを取り出す必要があります。そのため、診断プロセスの速度を低下させる間接的な余分なレイヤーです。

32 database  web-applications  rest  web-api 

異なるロールを持つ複数のユーザーが含まれるリソースにアクセスできるREST APIを構築しています。 スコープをシンプルに保つために、「student / teacher / class」ドメインを取り上げます。 GET /students アクセスするリソースです。 ユーザーには、学生や教師などの役割がある場合があります 生徒はクラスの生徒にのみアクセスできます。教師は、教えるクラスの生徒にアクセスできます。いくつかの用途は学生であり、他のクラスも教えます。彼らは彼らのクラスの生徒と彼らが教えるクラスの生徒にアクセスできなければなりません。 理想的には、これを2つの機能として実装します。ロールごとに1つ、ユーザーが複数のロールを持つ場合は「結合」します。 私の質問は、これを実装するためにどのパターンを使用すればよいですか？ 外部的に ロールごとにAPIを分割する必要がありますか？GET /teacher/studentsそしてGET /student/studentsそれは右の私には思われません。 すべてを維持する私は1つのリソースです（推奨） 内部的に 内部的にどのように実装する必要がありますか？ すべての方法は、BIGスイッチで開始する必要がありますか、役割ごとに行う必要がありますか 役割ごとにリポジトリを実装する必要がありますか？ これを達成するのに役立つ設計パターンはありますか？ 副次的なコメントとして：私はASP.NET Web APIとEntity Framework 6を使用していますが、概念的な実装には関係ありません。

27 design-patterns  programming-practices  rest  web-api 

RESTful APIの作成中、同じURLでHTTP動詞を使用する必要がありますか（可能な場合）、またはアクションごとに特定のURLを作成する必要がありますか？ 例えば： GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item または、次のような特定のURLを使用します。 GET /items # Read all items GET /item/:id # Read one item POST /items/new # …

25 rest  api-design  web-api 

スキーマレスJSON形式のように、APIを介してオブジェクトを転送する場合、存在しない文字列プロパティを返す理想的な方法は何ですか？下記のリンクの例のように、これを行うためのさまざまな方法があることを知っています。 nullを避ける nullを返す 空のプロパティを削除 私は過去にnullを使用したことがあると確信していますが、nullを使用する正当な理由はありません。データベースを処理するときにnullを使用するのは簡単なようです。しかし、データベースは実装の詳細のようで、APIの反対側の関係者には関係ありません。たとえば、おそらく値を持つプロパティ（null以外）のみを保存するスキーマレスデータストアを使用します。 コードの観点から見ると、文字列関数を1つの型string（null以外）のみで動作するように制限すると、証明が容易になります。nullを避けることもOptionオブジェクトを持つ理由です。したがって、要求/応答を生成するコードがnullを使用しない場合、APIの反対側のコードもnullの使用を強制されないでしょう。 nullの使用を避ける簡単な方法として、空の文字列を使用するというアイデアが好きです。空の文字列に対してnullを使用することについて聞いた1つの議論は、空の文字列はプロパティが存在することを意味するということです。私は違いを理解していますが、それが単なる実装の詳細なのか、nullまたは空の文字列を使用して実際の違いが生じるのかどうかも疑問に思います。また、空の文字列は空の配列に似ているのだろうかと思います。 それでは、これらの懸念に対処する最善の方法はどれですか？転送されるオブジェクトの形式（スキーマ/スキーマレス）に依存しますか？

25 web-api  data-types 

私はAPI構造のWebアプリケーションを作成していますが、このアプリケーションには独自の仕事をしているさまざまなレイヤーがあります。 最初のレイヤーはユーザー入力を検証する検証レイヤーであり、検証に合格した場合は2番目のレイヤー（アクセス制御レイヤー）に移動します。そうでない場合はエラーメッセージを返します 2番目の層は、ユーザーが実行したいタスクを実行する許可を持っているかどうかを確認するアクセス制御です。ユーザーが許可を持っている場合、要求を次の層に移動します。 3番目のレイヤーは、アプリケーションのロジックがあるコントローラーレイヤーです。 私の質問は、アクセス制御の前に検証レイヤーを持つことはOKですか？ユーザーが許可されていないタスクを実行しようとしており、検証エラーメッセージを送信している場合はどうなりますか？ユーザーはリクエストをエンドポイントに送信し、検証レイヤーと話します。検証に合格すると、メッセージが表示されます。You can't access this! 私には奇妙に感じますが、このようにうまくいくのでしょうか、それともインフラストラクチャの他の選択肢は何でしょうか？

24 validation  web-api  access-control 

これはおそらく、MicrosoftがASP.NET Web APIライブラリを作成したときから始まったものであり、少なくとも私が間違えなければ覚えているときです。とにかく、それ以来、そのHTTPパッケージは、JSONとのデータの（デ）シリアル化のためにNewtonsoft.Jsonライブラリに依存して開始されました。 マイクロソフトと同じくらい大きな会社がオープンソースライブラリへの依存を追加するのはなぜですか？私が知っている限り、それが依存関係として使用される唯一のMicrosoft以外のライブラリだったので、彼らが当時。 おまけの質問として、ジェームズ・ニュートン・キングはマイクロソフトから何らかの財政的支援を受けていますか？

18 .net  asp.net  json  web-api 

古き良き時代のリポジトリを今でも覚えています。しかし、リポジトリは時間とともにいものになりました。その後、CQRSが主流になりました。彼らは素晴らしく、新鮮な空気の息吹でした。しかし、最近、コントローラーのアクションメソッド（特にアクション自体が何らかのコマンド/クエリハンドラーであるWeb Api）でロジックを正しく維持しないように何度も自問しています。 以前は、そのための明確な答えがありました。すべてのそれらのモックできないシングルトンと全体的ないASP.NETインフラストラクチャでControllerをテストするのは難しいので、テストのためにそれをしました。しかし、時代は変わっており、ASP.NETインフラストラクチャクラスは、今日では（特にASP.NET Coreで）はるかに単体テストに適しています。 典型的なWebApi呼び出しは次のとおりです。コマンドが追加され、SignalRクライアントに通知されます。 public void AddClient(string clientName) { using (var dataContext = new DataContext()) { var client = new Client() { Name = clientName }; dataContext.Clients.Add(client); dataContext.SaveChanges(); GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client); } } 簡単に単体テスト/モックできます。さらに、OWINのおかげで、ローカルWebApiおよびSignalRサーバーをセットアップし、統合テストを実行できます（ちなみにかなり高速です）。 最近、面倒なコマンド/クエリハンドラを作成するモチベーションが低下し、Web Apiアクションにコードを保持する傾向がありました。ロジックが繰り返されるか、それが本当に複雑で、それを分離したい場合にのみ、例外を作成します。しかし、ここで正しいことをしているかどうかはわかりません。 典型的な最新のASP.NETアプリケーションでロジックを管理するための最も合理的なアプローチは何ですか？コードをコマンドおよびクエリハンドラーに移動するのが妥当なのはいつですか？より良いパターンはありますか？ 更新。DDD-liteアプローチに関するこの記事を見つけました。したがって、コードの複雑な部分をコマンド/クエリハンドラに移動するという私のアプローチは、CQRS-liteと呼ばれるようです。

15 .net  asp.net  web-api  cqrs  asp.net-mvc-web-api 

単一ページアプリケーションにREST APIを提供するASP.NET Web APIがあります。DTO / POCOを使用して、このAPIを介してデータを渡します。 問題は、これらのDTOが時間とともに大きくなっていることです。そのため、DTOをリファクタリングしたいと考えています。 DTOを設計する「ベストプラクティス」を探しています。現在、値型フィールドのみで構成される小さなDTOがあります。 public class UserDto { public int Id { get; set; } public string Name { get; set; } } 他のDTOは、構成によってこのUserDtoを使用します。例： public class TaskDto { public int Id { get; set; } public UserDto AssignedTo { get; set; } } また、他から継承することによって定義される拡張DTOがいくつかあります。たとえば： public class …

13 rest  api-design  web-api  dto  poco