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

単体テストを作成するときは、フィクスチャを使用するのが一般的です。テスト可能なデータが少ないため、次のように言えます。1.すべてのクライアントにWilly Wonkaを含めます。2.クライアント3を削除し、クライアントにWilly Wonkaが含まれないようにします。 単体テストではそれで問題ありません。セットアップ/ティアダウンを使用して、フィクスチャを再ロードするか、トランザクションをロールバックします。したがって、テストの作成、更新、削除はトランザクション内で行われます。新しい一時データは、そのテストの間だけ保持され、その後リセットされます。 しかし、RESTサーバーをRESTクライアントから分離した場合はどうでしょうか。 RESTクライアントが正しく読み取っているだけでなく、正しく作成、更新、削除されていることを確認します。 リモートテストRESTサーバーに対してこれを行う方法の例や提案を見つけることができませんでした。 フィクスチャのみを提供するテストRESTサーバーがあるとします。HTTPの完全なステートレスの性質は、「BEGIN TRANSACTION」と「ROLLBACK TRANSACTION」または「RELOAD FIXTURES」タイプのメッセージを送信するのが難しいことを意味しますよね？ 私はこれを最初にしたくないので、これについて別の考え方が必要だと感じています。 助言がありますか？

10 unit-testing  api  rest 

このような： Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" referenceIdが心配です。 システムドメインは、さまざまな形式（xml、excel）のデータのエクスポートおよびインポートを通じて、サードパーティと多くの方法で統合されるプラットフォームです。サードパーティがAPIを介してシステムと統合できるように十分に成熟しており、このAPIの設計がこの疑問を引き起こします。 リソースを識別して取得するために使用できるIDを持つオブジェクト、キャンペーンがあります。APIの利用者は、ドメイン内のキャンペーンと見なすものへの独自の参照コードを持っている場合があります。 私たちのシステムには、このようなサードパーティの参照フィールドを持つ他のオブジェクトがあり、既存のコンシューマーから期待されています。ただし、マッピングの負担がかかり、このreferenceIdが何であるか（数値、テキスト、json？）がわからないため、新しいコンシューマー向けの混乱するプロパティがAPIに追加されます。 APIのパブリックオブジェクト定義でサードパーティの参照IDフィールドを許可することは、不適切な手法または不適切な設計と見なされますか？

9 rest  api  domain-driven-design  api-design  single-responsibility 

次の応答モデルを吐き出すHTTP APIエンドポイントを取ります。 { "type": "Dog", "name": "Jessi", ... } typeフィールドは次のいずれかであるとしてドキュメントに記載されているDog、CatまたはFish。 新しいオプションの追加は、たとえばRat、重大なAPIの変更と見なされますか？ 有限リスト（開発者がオンにする可能性がある）にオプションを追加することは、APIの拡張または変更と見なされますか？

9 rest  api  api-design  json 

RESTについての理解は、サービス操作を状態の表現としてモデリングし、HTTPを使用してある状態から別の状態に遷移することを可能にします。リソースをサービスサイドの状態の表現として常に理解してきました。最近まで、コミュニティから尊敬されている賢い開発者/アーキテクトであることがわかっているJimmy Bogardによるこの記事を読みました。その投稿から特定のステートメントを引用するには 表現は少し異なります- リソースの現在の状態を示します（要求されたとき）。 これは私を混乱させました。このトピックについて一般的に受け入れられている意見は何ですか？

9 rest  api  api-design 

DELETE、POST、またはPUTなどの一部のentpoindに対して、エラーを返す可能性のある検証ルールがあるREST APIを持っています。 クリティカルではないエラーのような新しいタイプのエラーが必要になりました。通常の方法でエラーが発生するはずですが、「警告の抑制」フラグが送信された場合はアクションに進む必要があります。このようなユーザーは、「このステータスを変更してもよろしいですか、まだ完了していません」と尋ねることができます。 質問：これらのタイプのエラーのベストプラクティスはありますか？ 二次質問： 私が使用できるような動作のHTTPセマンティクスはありますか？ 私はまだRESTのアイデアに従っていますか（私にとってはそうです）-私はそれをステートレスに保ちます

9 rest  api 

ある種のデータベースに永続化されているある種のデータ構造があるとします。簡単にするために、このデータ構造を呼びましょうPerson。これで、他のアプリケーションがを作成、読み取り、更新、および削除できるようにするCRUD APIを設計する必要がありますPerson。簡単にするために、このAPIが何らかのWebサービスを介してアクセスされると仮定します。 CRUDのC、R、Dパーツのデザインはシンプルです。私はC＃のような関数表記を使用します-実装はSOAP、REST / JSON、またはその他の可能性があります。 class Person { string Name; DateTime? DateOfBirth; ... } Identifier CreatePerson(Person); Person GetPerson(Identifier); void DeletePerson(Identifier); アップデートはどうですか？自然なことは void UpdatePerson(Identifier, Person); しかし、どのフィールドを更新するかをどのように指定しますPersonか？ 私が思いつくことができる解決策： 常に完全な Personを渡すように要求することができます。つまり、クライアントは次のようにして生年月日を更新します。 p = GetPerson(id); p.DateOfBirth = ...; UpdatePerson(id, p); ただし、そのためには、GetとUpdateの間にトランザクションの整合性またはロックが必要になります。そうしないと、他のクライアントによって並行して行われた他の変更を上書きする可能性があります。これにより、APIがさらに複雑になります。さらに、次の疑似コード（JSONをサポートするクライアント言語を想定）であるため、エラーが発生しやすくなります。 UpdatePerson(id, { "DateOfBirth": "2015-01-01" }); -これは正しいように見えます-DateOfBirthを変更するだけでなく、他のすべてのフィールドをnullにリセットします。 であるすべてのフィールドを無視できますnull。しかし、それを変更しないこと DateOfBirthと、意図的にnullに変更することの違いをどのように作成しますか？ 署名をに変更しますvoid UpdatePerson(Identifier, Person, ListOfFieldNamesToUpdate)。 署名をに変更しますvoid …

9 design  api  web-services  api-design  crud 

ユーザーがフォームを更新するたびに元に戻す履歴を作成したい。更新なので、PUTリクエストを使用したいと思います。ただし、PUTには副作用が必要ないことを読みました。 ここでPUTを使用することは許容されますか？より良い代替案はありますか？ PUT /person/F02E395A235 { time: 1234567, fields: { name: 'John', age: '41' } } サーバー内 doPut('person/:personId', // create a new person snapshot ) 編集： 履歴はユーザーに表示され、複数回呼び出すと複数のバージョンになります。 解決策は、バージョンを作成する前にバージョンが一意であるかどうかを確認することでした。

9 language-agnostic  api  rest 

いくつかの統計情報を返すAPIエンドポイントがあります。現在、応答は次のようになります。 オプション1： { "stats": [ { "name": "some-stats-key1", "value": 10 }, { "name": "some-stats-key2", "value": 20 } ], ... other keys } しかし、これは少し複雑に見え、私はそれをどのようにするのか： オプション2： { "stats": { "some-stats-key1": 10, "some-stats-key2": 20 } ... other keys } オプション1は拡張が簡単ですが、ユーザーにとって快適ではないことを理解しています。これらのオプションのいずれかを使用して直面する可能性がある他の問題は何ですか？または、次のようなハイブリッドソリューションを作成する必要があります。 オプション3： { "stats": { "some-stats-key1": { "name": "some-stats-key1", "value": 10 }, "some-stats-key2": { …

9 rest  api  json 

現在、会社で使用するアプリケーションを計画しています。デスクトップアプリケーションをビルドするために必要です。現在のところ、近い将来、アプリケーションがモバイルまたはブラウザーで利用可能になるかどうかは不明です。 私には2つの可能性があります。 デスクトップアプリケーションから直接データベースにアクセスする REST APIを作成してこれに接続する アプリケーションが社内のデスクトップアプリケーションのみである場合、REST APIを使用できますか？それが可能であることは知っていますが、「正しい」方法ですか？（ベストプラクティス） REST APIを直接作成することには、いくつかの（可能な）利点と欠点があります。 短所： 開発に時間がかかる より複雑 サーバーはより多くの作業を行います セキュリティ上の問題 もっとゆっくり？（サーバーとデスクトップアプリケーションは同じネットワーク上にあります） 利点： 他のプラットフォームへの移行は簡単です ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません 複雑さについても同じ セキュリティ（コメントでtkauslが言及） 保守性（WindRavenによるコメントでの言及）

9 architecture  rest  api  desktop-application 

私はこの方法でこの質問をします-私のREST APIを「正しい」方法で実装しないことのソフトウェアエンジニアリングの懸念は何ですか？ 「正しい」方法とはどういう意味ですか？まあ、私が正しい方法についての私の認識を説明できるようにしてから、私がそれをどのように行っているかを説明します（また、JSON REST APIについて話していると仮定します）。 正しい方法 無国籍。これは私が得る部分です。クライアントは常に100％いつまでも状態を維持します。それはサーバーの仕事ではなく、クライアントの仕事です。 各動詞の予想されるアクションと応答： GET-完全に指定されたリソースを取得します。リクエストの承認またはクエリパラメータのいずれかによってのみ制限されます。これにより、プロセス内のリソースが変更されることはありません。 POST-リソースの説明全体（JSONオブジェクトなど）を指定すると、リソースを作成し、日付やIDなどのサーバー側のプロパティも作成してそのリソースを返します。 DELETE-指定されたリソースを削除し、応答として何らかの200 OKのみを与えます PUT -指定されたオブジェクト全体宣言入力として、入力で与えられたフィールドのそれぞれにリソースのすべてのフィールドを更新し、特定の場所でリソースを更新します。明確にするために、これはオブジェクト全体が入力として渡されることを期待しています。更新されたリソース全体が、すべてのフィールドとともに（許可またはその他の入力フラグに従って）返されます。 PATCH-リソースの変更が必要なフィールドのみを指定して、入力として指定された指定されたリソースのフィールドのみを更新します。（これは私が不明瞭なところです）：リソース全体が返されますか？（または、更新されたフィールドだけですか？Dunno。気にしないでください。） リソースパス。リソースの相互関係を考えると、リソースパスは次のいずれかになります。 / parentresource /：id / parentresource /：id / childresource / parentresource /：id / childresource /：childId / parentresource /：id / childresource /：childId / subresource /：subresourceId（この例では、サブリソースは、親リソースに属する子リソースに属しています）。 やりたいこと 上記は、REST APIがどのように機能するかについての私の理解です。次に、上記のバリエーションのいくつかをリストします。 PUT / PATCH-変更のためにリソース全体を渡すポイントは何ですか？リソースの変更にはPUTのみを使用し、更新するフィールドのみを渡します。その結果、パッチを使用する必要はありません リソースパス-アプリケーションでGUIDを使用しています。その結果、それらは世界的にユニークになります。単独でサブリソースを一意に参照できるのに、親リソースを含む完全なリソースパスが必要なのはなぜですか？以下のような： /サブリソース/：subresourceId ：もし私のような完全なパスが必要となるサブリソースを参照しようとし、それを「正しい」やり方をやっていた / parentresource …

8 design  rest  api  standards 

当社は、数千のサービスを含むマイクロサービスアーキテクチャでアプリケーションを実行しています。50以上のサービスと通信するバックエンドアプリケーション「X」に取り組んでいます。フロントエンドサービスは他のサービスでリクエストを実行するためにサービス「X」を呼び出します。 問題点： フロントエンドは、他のサービスで何かが失敗したときに、ユーザーフレンドリーなメッセージを表示したいと考えています。 他のサービスはユーザーフレンドリーなメッセージを返しません。いくつかあるため、他のチームに変更を依頼することはできません。 そのような合意されたエラーコードはありません。他のサービスは文字列エラーメッセージを返します。現在、UIに渡されます。時々、エラーメッセージはポインタ参照です（悪いコード：/） 可能な解決策： エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。 スケーラブルで持続可能なソリューションに関する他のアイデアはありますか？ありがとう！

8 api  microservices  error-handling 

私が作成しているAPIにHTTPリクエストを行うサードパーティは、APIが1秒未満で応答することを要求しています。私の質問は、彼らが道持っているされて（文字通りあらゆるの範囲内で、道をHTTPおよび/またはTCP / IPプロトコル）それは長い1秒以上かかる場合は、私のコードの実行を中止するには？

8 c#  api  asp.net  http  asp.net-core 

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。 エンドポイント： POST /register/ POST /login/ POST /logout/ POST /password/change/ 実装： POST /register/： リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。 サーバーアクション： 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。 JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。 応答：サーバーはJSONでアクセストークンと更新トークンを返します。 POST /login/： リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。 サーバーアクション： 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。 レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。 POST /logout/： 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。 サーバーアクション： 更新トークンデータベースをチェックして、更新トークンを検証します。 データベースから更新トークンを削除します。 注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。 POST /password/change/： リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。 サーバーアクション： アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。 データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。 リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。 質問： このアプローチは安全ですか？具体的には： HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？ 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？ クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？ リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

8 design  rest  api  security  authentication 

偽のREST APIを非難する彼自身の記事に関するロイフィールディングのコメントから： 真にRESTfulなAPIはハイパーテキストのように見えます。すべてのアドレス可能な情報単位は、明示的に（たとえば、リンクとID属性）または暗黙的に（たとえば、メディアタイプの定義と表現構造から派生）のいずれかでアドレスを伝達します。クエリ結果は、オブジェクト表現の配列ではなく、要約情報を含むリンクのリストで表されます（クエリはリソースの識別の代わりにはなりません）。 これは、たとえば、最近ログインした100人のユーザーのリストをクエリして、その名前と電子メールを表示する必要がある場合、最初GETに結果のリストをクエリする必要があることを意味します。リンク要素のリストであり、各リンクオブジェクトにはユーザーリソースのURIが含まれます。結果を表示するために必要なデータを実際に取得する前に、さらに 100のGETリクエスト（ユーザーリソースごとに1つ）を行う必要があります。 それは信じられないほど非効率的です。1つまたは2つの要求で必要なデータを取得するための本当にRESTfulな方法は他にありませんか？

8 rest  api  api-design 

高度にモジュール化された小さなコンポーネントを使用して設計されたWebアプリ（この場合はAngularJSディレクティブを使用しますが、WebComponents、ReactJSコンポーネント、またはその他のテクノロジと同じくらい簡単にできます）。多くの場合、コンポーネントには、初期化時またはユーザーの操作時に非同期REST API呼び出しがあります。この設計により、ページごとに多くのAPI呼び出し（20以上の場合もあります）が発生しています。このデザインに問題はありますか？シングルトンとして機能するより大きなクライアント側サービスにAPI呼び出しを圧縮することを提案している人もいます。したがって、ページがそのデータの一部しか使用しない場合でも、10回のAPI呼び出しは1回に削減される可能性があります。赤い旗、またはこのデザインの問題はありますか？どちらを優先すべきですか？

8 rest  api  async