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

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

9 rest  api  api-design  json 

JWT仕様では、ペイロードとその送信方法のみが記述されていますが、認証プロトコルは開いたままになっているため、柔軟性が得られますが、残念ながら柔軟性により、アンチパターンや設計ミスが発生する可能性があります。 私はJWT認証のためによく考えテストされたエンタープライズパターンを探しています。これは使用または適応できますが、完全なものを見つけることができませんでした。 私が考えていたのは： Authorizationヘッダーが満たされていない場合、またはJWTトークンが無効であるか、期限切れの場合は、HTTP 401を送信します。 認証するには、/ login RESTチャネルを使用し、JSONオブジェクトとしてユーザー名とパスワードを送信します トークンを存続させるには、/ keepalive RESTチャネルを使用し、N（5）分ごとに呼び出し、新しいJWTトークンを受け取り、呼び出しごとに既存のトークンを置き換えます（トークンはM（15）分後に期限切れになります）。 ただし、私を邪魔するのは、その/ keepaliveチャネルの必要性です。一方、ユーザーが不在の場合（キープアライブが必要かどうかの決定がまだ満たされていない場合）であっても、認証が期限切れになるのを防ぐ必要があります。もちろん、これらは追加の呼び出しであり、プロトコルの追加の複雑さです。興味深いのは、サーバーが自動的にトークンを延長することです。セッションベースの環境では、タイムスタンプをリセットすることで発生しますが、ここではサーバーが新しいトークンを送信する必要があります。毎回ではなく、トークンがR（たとえば10）分で期限切れになると送信されます。ただし、応答本文に配置することは、JSON応答プロトコルを変更することを意味し（したがって、ソリューションは侵襲的で透過的ではありません）、クライアントが処理できる追加のHTTPヘッダーを配置することは、必ずしも良いパターンであるとは限りません。私' 私のオープンポイントに答える、すぐに使えるエンタープライズパターンはありますか？プロトコルドラフトは信頼できるアイデアですか？ゼロからデザインするよりも、すぐに使えるものを使いたいです。

9 rest  authentication  architectural-patterns 

REST APIの作成を進めており、現在、次の問題が発生しています。 Foo最初のリソースです。CRUD操作は/foo/URI を介して適用できます。 Bar2番目のリソースです。CRUD操作は/bar/URI を介して適用できます。 Every Fooは0または1に関連付けられていますBar。のBarサブリソースとして扱わないのFooはBar、複数Fooのs 間で同じインスタンスを共有できるためです。ですから、の代わりに独立したURI経由でアクセスする方がよいと考えました/foo/[id]/bar。 私の問題は、かなりの場合、インスタンスを要求するクライアントがFoo関連するインスタンスにも関心があることBarです。現在、これは、1つではなく2つのクエリを実行する必要があることを意味します。1つのクエリで両方のオブジェクトを取得できる方法を紹介したいのですが、そのためのAPIをモデル化する方法がわかりません。これまでに思いついたこと： 次のようなクエリパラメータを導入できます/foo/[id]?include_bar=true。このアプローチの問題は、応答のリソース表現（JSON構造など）が異なるように見える必要がある（たとえば、{ foo: ..., bar: ... }単にシリアライズされたものではなく、コンテナーなどFoo）ため、Fooリソースエンドポイントが「異種」になることです。それは良いことではないと思います。をクエリする場合/foo、クライアントはクエリパラメータに関係なく、常に同じリソース表現（構造）を取得する必要があります。 もう1つのアイデアは、新しい読み取り専用エンドポイントを導入すること/fooandbar/[foo-id]です。この場合、のような表現を返すことは問題ありません。これ{ foo: ..., bar: ... }は、fooandbarリソースの「公式」表現にすぎないためです。ただし、そのようなヘルパーエンドポイントが本当にRESTfulであるかどうかはわかりません（これが質問のタイトルに「can」と書いた理由です。もちろん、技術的には可能ですが、それが良いアイデアかどうかはわかりません）。 どう思いますか？他の可能性はありますか？

9 rest  web-api  resources 

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

9 rest  api  api-design 

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

9 rest  api 

環境 RESTアーキテクチャスタイルのステートレス性により、各リクエストは完全に独立しており、サーバーはクライアントに関する情報を決して保存しません。 したがって、どのクライアントがリソースのロックを取得するかをサーバーストアに要求するため、悲観的な同時実行制御は適していません。次に、Etagヘッダーを使用して、オプティミスティック並行性制御が使用されます。（ところで、私がそこに尋ねたように/programming/30080634/concurrency-in-a-rest-api） 問題 楽観的同時実行制御メカニズムの主な問題は、すべてのクライアントがいつでも任意の操作を実行できるようにすることです。 そして、RESTの無国籍原則を破ることなく、それを回避したいと思います。つまり、すべてのクライアントがいつでも操作を実行することはできません。 質問 私の考えでは、次のような準楽観的同時実行制御メカニズムで可能です。 クライアントはトークンを要求できます 生成できるトークンは1つだけで、有効期間は限られています リソース（POSTやPUTなど）で操作を実行するには、クライアントはこのトークンをリクエストの本文（またはヘッダー？）の一部として渡す必要があります。トークンを持たないクライアントは、これらの操作を実行できません。 これは、楽観的同時実行制御に非常に似ていますが、「すべてのクライアントがすべての操作を実行できる」とは逆に、1つのクライアントのみが一部の操作（トークンを取得したクライアント）を実行できる点が異なります。 このメカニズムはRESTアーキテクチャスタイルと互換性がありますか？それはその制約のいずれかを破りますか？私はSOについて質問することを考えていましたが、これはソフトウェア設計に関連する、よりハイレベルな質問のようです。

9 design  architecture  rest  concurrency 

ユーザーがフォームを更新するたびに元に戻す履歴を作成したい。更新なので、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 

REST [api]構造とOOモデルを比較すると、次のような類似点があります。 どちらも： データ指向ですか REST =リソース OO =オブジェクト データを取り巻く操作 REST =リソースをVERBS（Get、Postなど）で囲みます OO =カプセル化によってオブジェクトの周りの操作を促進する ただし、適切なOOプラクティスは、たとえばファサードパターンを適用しようとするときにREST APIに常に依存しているわけではありません。RESTでは、すべてのリクエストを処理する1つのコントローラーがなく、内部オブジェクトの複雑さを隠しません。 それどころか、RESTは、少なくとも2つの形式で、リソースとその他のすべての関係のリソース公開を促進します。 リソース階層関係を介して（id 43の連絡先はアドレス453で構成されます）： /api/contacts/43/addresses/453 REST json応答のリンクを介して： >> GET /api/contacts/43 << HTTP Response { id: 43, ... addresses: [{ id: 453, ... }], links: [{ favoriteAddress: { id: 453 } }] } OOに戻ると、ファサードの設計パターンLow Couplingは、objectAとその「objectBクライアント」の間、およびHigh CohesionこのobjectAとその内部オブジェクト構成（objectC、objectD）を尊重します。とをObjectAのインターフェースは、これは、許可に制限の影響に現像剤をObjectBのObjectAに（内部変化ObjectCに及びobjectD長いほど）、ObjectAにする API（操作）が依然として尊重されます。 …

9 http  rest  definition 

Client application-> Front-end API cloud server->のような3層システム用のREST APIを設計していますuser's home API server (Home)。 Homeはホームデバイスであり、Front-endWebsocketまたは長い投票（これは、RESTに違反している最初の場所です。後でさらに悪化します）を介した接続を維持することになっています。Front-endほとんどの場合、Client要求をHome接続にトンネルし、一部の呼び出し自体を処理します。にHome通知を送信することがありますClient。 Front-endHome基本的に同じAPI を持っています。LAN経由で直接Client接続している可能性がありますHome。この場合、それ自体にHomeいくつかのClientアクションを登録する必要がありFront-endます。 このシステムでのRESTの長所は次のとおりです。 RESTは人間が読める形式です。 RESTには、動詞（CRUDなど）、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。 HTTP上で動作し、可能なすべてのプロキシを渡します。 RESTコントラは次のとおりです。 リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。必要な接続が壊れていて、あるはずだったことを知るためだけに、非同期呼び出しにFront-end戻る場合があります。202 AcceptedHome503 Homeにメッセージを送信する必要がありますClient。ClientポーリングするFront-endか、接続を維持する必要があります。 我々は考えているWAMP / アウトバーンを、それがすでにメッセージキューのように見ていることを私を襲ったとき、機能をパブリッシュ/サブスクライブを取得するのWebSocketの上に。 一種のメッセージングキューをトランスポートとして評価する価値はありますか？ メッセージキューの逆のように見えます： CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか？ これらの考慮事項はどのくらい深刻ですか？

9 architecture  web-services  rest  message-queue  websockets 

現在、従来の顧客データにアクセスするためのREST APIを設計しています。APIの要素の1つは、ユーザーの資産です。アセットは特定のサービスの下に追加されます。バックエンドAPIは、特定のサービスのユーザーにのみアセットを追加します。したがって、User--Asset関係はありませんが、User-[Service]-Asset関係があります。 URIは次のようになります。 /users/{id}/assets/{id}/services/{id} APIを使用すると、新しいエントリを作成するためのアセットIDとサービスIDがわかります。私たちが苦労しているのは、この関係の創造です。 簡単な方法の1つは、関係全体を /users/{id}/assets/ POST /users/{id}/assets {asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"} しかし、URIが示すように実際にアセットを作成するのではなく、アセットとサービスの関係を作成します。 別の方法として、次のように関係をアドレス指定するURIにPOSTすることを検討しています。 POST /users/{id}/assets/{id}/service/{id} {attribute1:"{var}", attribute2:"{var}"} ただし、この場合、リソースパス/users/{id}/assets/{id}はPOSTの前には存在せず、副作用として作成されます。 まだ存在しないリソースパスへのPOSTはまったく許可されていますか？ あなたの考えをありがとう、 ジェラール。

9 design  design-patterns  rest 

クライアント証明書を使用してクライアントが認証されるREST APIを構築しています。この場合のクライアントは、個々のユーザーではなく、ある種のプレゼンテーション層です。ユーザーはカスタムアプローチを使用して認証され、これが適切に行われたことを確認するのはプレゼンテーションレイヤーの責任です（注：これは適切なアプローチではないことを知っていますが、APIはパブリックではありません）。 リクエストごとに（パスワードではなく）ユーザー名を渡したいのですが、これをどこで行うのかわかりません。Authorizationヘッダーを使用するのは良い考えでしょうか？

9 rest  authentication  headers 

UIコードが同じチームによって開発されるが、サービスレイヤー（REST / Java）とは異なる言語（Python / Django）で開発されるプロジェクトがあります。各レイヤーのコードは、異なるコードリポジトリに存在し、異なるリリースサイクルに従うことができます。UIレイヤーの観点から、サービスレイヤーの重大な変更を防止/軽減するプロセスを考え出そうとしています。 UIまたはサービスレイヤー（2つのGitリポジトリにあるコードをビルドするためのCIツールとしてJenkinsを使用しています）を構築するたびに実行するUIレイヤーレベルで統合テストを作成することを考えました。障害が発生すると、サービスレイヤーで何かが壊れ、コミットが受け入れられません。 また、サービスレイヤーの開発者に、UIレイヤーに存在するRESTサービスのクライアントライブラリを作成および保守してもらい、UIレイヤーに重大な変更があった場合に更新するようにしてもよいでしょうか（ベストプラクティスですか？）。彼らのサービスAPI？おそらく、UIコードが構築する静的に型付けされたAPIの利点があるでしょう。クライアントライブラリAPIが変更された場合、UIコードはコンパイルされません（したがって、重大な変更があったことがすぐにわかります）。また、UIまたはサービスレイヤーの構築時に統合テストを実行して、UIとサービス間の統合が引き続き機能することをさらに検証します。

9 rest  django 

これは、Jerseyを使用してJEE Glassfishサーバーで実行しようとしていることです。 @GET @Path("/{name}/{date}") public String getMessages(@PathParam("name") String name, @PathParam("date") Date date) このRESTfulなWebサービスを利用する人々に「ここの日付はJavaのDateクラスで機能するものなら何でもよい」と伝えることができるというアイデアが気に入っています。これは、Date仕様だけを見ることができるという観点からは非常に単純であり、テストできる動作モデルが既に用意されています。 私が心配している問題は、これを行ったときに、Date（）がコンストラクターで取得した内容が気に入らない場合、JAX-RSがあまり良くないことです。Date（）は、与えられたものを解析できない場合（実際の日付ではなく「today」という文字列を渡した場合など）にエラーをスローするため、JEEサーバーは404エラーを返します。 これは良い習慣ですか？私が考えていない、これを行うより良い方法はありますか？

9 rest  date-format 

お客様のアカウント情報を公開するためのRESTful APIを設計しています。現在のリソースに関連する他のリソースへの参照を含む表現があります。これは、公開APIや公開資料で見つけたいくつかのベストプラクティスからのものです。表現は、XMLまたはJSONのいずれかです。 たとえば、アカウントリソースの場合、アカウントのアドレスへの参照があり、ページ番号付きリストリソースの場合、最初、次、および前のページへの参照があります。 APIは<link title="" rel="" href="" />、O'Reillyの本に記載されているセマンティックリンクを使用して最初に設計され、NetflixとGoogleによってAPIで使用されました。QAエンジニアがオートメーションスイートを作成するときがきたとき、リンクの逆シリアル化に問題がありました。FacebookとTwitterのAPIで使用されている、より単純なuri文字列要素を提案しました。 私たちのQA技術者たちは、それ以来、逆シリアル化の問題を解決しましたが、セマンティックリンクでの現在のAPI仕様の使いやすさにはまだ不安があります。以前のXML-RPC APIはユーザーにとって難しすぎたため、私たちのAPIは主にお客様と一部のサードパーティパートナーシップによって使用されます。RESTに移行しました。 tl; dr; 質問： セマンティックリンク表現を実装した人が、困難を伴う消費者の問題を経験しましたか？ アップデート（6/21）：セマンティックリンクを使用することにし、混乱がエッジケースであることを期待します。APIが一部のコンシューマーでライブになったら、私たちの経験で質問に答えることを忘れないでください。 編集：例を追加 セマンティックアカウントJSON： { "username": "paul", "links": [ { "title": "addresses", "rel": "related", "href": "http://example.com/account/paul/addresses" }, { "title": "history", "rel": "related", "href": "http://example.com/account/paul/history" } ] } セマンティックアカウントXML： <account> <username>paul</username> <link title="addresses" rel="related" href="http://example.com/account/paul/addresses" /> <link title="history" …

9 rest  semantics 

HATEOASは「アプリケーション状態のエンジンとしてのハイパーメディア」の頭字語です。「アプリケーション状態のエンジン」とは何ですか。特に、「ハイパーメディア」のエンジンはどうですか。 私が理解できる限り、HATEOASとHALなどの関連する標準はRESTの「発見可能性」の部分に対応しています。 春の議論それについては、のように要約したものです。 HATEOASを使用すると、出力により、仕様やその他の外部ドキュメントを検索せずに、サービスと対話する方法を簡単に収集できます。 たとえば、HAL準拠のJSONなどを使用してHATEOAS準拠の応答を行う場合、クライアントはルートAPI URL以外のリソースパスをハードコーディングする必要がないということです。 「アプリケーションの状態」とは関係がないように見えることを除いて、これは完全に理にかなっています。せいぜい、サーバー構成（つまり、リソース（サーバー構成）のURLを変更した場合）を使用することで、コンシューマはどこにあるかを見つけることができます。 HATEOASが何であるかを私が収集できたことについて少し詳しく説明すると、同じ説明ページからの抜粋があります。HATEOASがリソースの場所を発見する問題を解決したことが示されています。ただし、「アプリケーションの状態」とは関係がないようです。 単純なJSONプレゼンテーションは、伝統的に次のようにレンダリングされます。 { "name" : "Alice" } 顧客データはありますが、データには関連するリンクは含まれていません。 HATEOASベースの応答は次のようになります。 { "name": "Alice", "links": [ { "rel": "self", "href": "http://localhost:8080/customer/1" } ] } この応答には、その人の名前だけでなく、その人がいる自己リンクURLも含まれています。

9 rest  hateoas