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

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のみをサポートするものとして文書化されている、新しく作成されたRESTful APIの使用を伴うサービスの実装を担当しています。 クライアントは、一貫して「application / json」のacceptヘッダーと「application / json」のcontent-typeで要求を行います。ただし、一部のエンドポイントは、HTMLのコンテンツタイプ、さらにはHTML本文で応答を送信します。私にとってこれは明らかに間違ったアプローチであり、正当化することはできません。 プロジェクト全体を通して、この同じプラクティスが2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントはこれに対処する必要があると述べており、デフォルトの「箱から出して」これに対処しないため、選択したRESTライブラリでさえ疑問視されています（RestEasy）。 これはフラストレーションの大きなポイントでした。私の主張を裏付ける多くの参考文献を見つけることができません。これは、それが非常に明白であるので、ポイントが議論の余地があるからだと思います。 問題は、何かが足りないということですか？私はこれについて熱心ですか？このシナリオでcontent-typeのapplication / jsonを持たないJSON APIを使用しても大丈夫ですか？参照をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？

25 rest  api-design  json  bad-code 

私の仕事のために、私たちが持っているいくつかのウェブサイトを動かすために使用する素敵なRESTfulウェブサービスがあります。基本的に、Webサービスを使用すると、サポートチケットを作成および操作でき、Webサイトがフロントエンドを担当します。Webサービスリクエストでは、認証ヘッダーを使用します。このヘッダーを使用して、呼び出しごとにユーザーとパスワードを検証します。 今年は、Webサイト上のユーザーがGoogle、Twitter、Facebook（おそらく他のユーザー）経由でログインできるように、ログインオプションを拡張することを検討しています。ただし、Webサービスがサードパーティの認証プロバイダーを使用して、ユーザーが本人であることを確認できるように、これをどのように設計するかについて多くの問題を抱えています。これを行うためのベストプラクティスはありますか？ 現在、Webサイトでユーザー自身の認証を処理してから、現在のセッションをWebサービスバックエンドに登録する新しいsetSessionId呼び出しを使用することを考えています。Webサービスへの追加の各リクエストは、そのセッションIDを渡し、検証します。これらは大丈夫のように見えますが、私はこれを考えていないという私の頭の後ろの感覚を持っています、そして私のすべてのフォーラムの閲覧とoauthとopenidの仕様を読んでいるだけでもっと混乱させられます。これに取り組む方法のヒントはありますか？

25 web-services  rest  authentication  oauth  openid 

変更のための先見の明を持つ外部アプリケーション用のAPIを設計しようとすることは簡単ではありませんが、少し前もって考えておくことで、後で生活が楽になります。私は、以前のバージョンのハンドラーをそのままにしておくことで、後方互換性を維持しながら将来の変更をサポートするスキームを確立しようとしています。 この記事の主な関心事は、特定の製品/会社に対して定義されたすべてのエンドポイントでどのパターンに従う必要があるかです。 基本スキーム のベースURLテンプレートを考えると、https://rest.product.com/すべてのサービスが/api、/authおよびなどの他の非レストベースのエンドポイントと共に存在することを考案しました/doc。したがって、次のようにベースエンドポイントを確立できます。 https://rest.product.com/api/... https://rest.product.com/auth/login https://rest.product.com/auth/logout https://rest.product.com/doc/... サービスエンドポイント 次に、エンドポイント自体について説明します。懸念はPOST、GET、DELETEこの記事の主な目的ではなく、それらのアクション自体に懸念されます。 エンドポイントは、名前空間とアクションに分類できます。また、各アクションは、戻り値の型または必須パラメーターの基本的な変更をサポートする方法で表示される必要があります。 登録されたユーザーがメッセージを送信できる架空のチャットサービスを利用すると、次のエンドポイントがある場合があります。 https://rest.product.com/api/messages/list/{user} https://rest.product.com/api/messages/send 今度は、壊れる可能性のある将来のAPI変更に対するバージョンサポートを追加します。私たちは、どちらかの後にバージョンの署名を追加することができ/api/たりした後/messages/。与えられたsendエンドポイント我々は、v1の以下のものを持つことができます。 https://rest.product.com/api/v1/messages/send https://rest.product.com/api/messages/v1/send だから私の最初の質問は、バージョン識別子の推奨場所は何ですか？ コントローラーコードの管理 そのため、以前のバージョンをサポートする必要があることを確立しました。そのため、時間の経過とともに廃止される可能性のある新しいバージョンのそれぞれのコードを何らかの方法で処理する必要があります。Javaでエンドポイントを記述していると仮定すると、これをパッケージで管理できます。 package com.product.messages.v1; public interface MessageController { void send(); Message[] list(); } これには、すべてのコードがネームスペースを介して分離されているという利点があります。この場合、重大な変更はサービスエンドポイントの新しいコピーを意味します。これの不利な点は、すべてのコードをコピーする必要があり、新しいバージョンと以前のバージョンに適用するバグ修正を各コピーに適用/テストする必要があることです。 別のアプローチは、エンドポイントごとにハンドラーを作成することです。 package com.product.messages; public class MessageServiceImpl { public void send(String version) { getMessageSender(version).send(); } // Assume we have …

25 design  design-patterns  web-services  rest  services 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 HTTPベースのAPIと呼び、URIを使用してリソースとHTTP動詞（PUT、POST、DELETE、GET ...）に名前を付け、それらのリソースを操作しますか？ ロイ・フィールディングの苦情によると、ハイパーメディアがないため、RESTではありません。 内部的には、私のチームでは、誰もが「REST API」と呼んでいます。私はそれを「RESTライク」と呼んでいますが、説明的ではなく、その意味はあいまいです。RESTについては大きな意見の相違があるため、私はそれについてかなり混乱しています。火炎戦争に参加したくないのですが、正しい用語を使用してください。

24 terminology  rest  api  http 

ユーザーが常にいくつかの「プラン」のいずれかを使用するプロジェクト用のREST APIを設計しています。各プランは、アカウントに含めることができるユーザーの最大数やアップロードできるデータの最大数など、リソースの制限を定義します。これらの制限の1つに達すると、ユーザーはプランをアップグレード（基本的に支払い）して、より多くのリソースを取得できます。 アカウントのリソース制限のためにアクションを実行できない状況を示す特別なステータスコードを返します。プランをアップグレードすると解決します-たとえば、ユーザーがストレージ容量の100％を使用して追加のファイルをアップロードしようとした場合、彼らはこの応答を受け取ります。 候補者は次のとおりです。 403 Forbidden -ただし、このケースと、ユーザーがこのアクションを実行するための許可を単に持たない他のケースとを区別したいと思います。 401 Unauthorized -良いアイデアではありません。認証関連の問題にこれを使用しています。 402 Payment Required -ある意味理にかなっていますが、標準ではないが予約済みのステータスコードの使用が心配です 423 Locked将来的には他のものに使用する可能性が低いため、さらに標準以下のもの 別のオプションは、非常に標準的なもの403を使用することです。ただし、応答本文にエラーの詳細を示します。 どのアプローチが（a）長期的に最も効果的であり、（b）RESTfulな原則にもっとうまく適合すると信じているのか疑問に思っています。

24 rest  api-design  http 

製品、ブログ投稿など、リソースのデータベースがあります。パブリックWebサイト用に、それらに対処するURLスキームを設計する必要があります。 データベースIDがバインドされている2つの例を次に示します。 https://www.youtube.com/watch?v=7FPS6llqhXw http://www.amazon.co.uk/gp/product/B000NHOMSQ わかりやすい例は次のとおりです。 http://en.wikipedia.org/wiki/LED_circuit （そこでのブラウジング生活を少し垣間見ます） メールまたはドキュメントでホバーまたは表示するときにURLの末尾に何があるかを知っているので、わかりやすいURLが好きです。SEOの方が良いか、以前はそうでした。 ドキュメントまたは製品の名前が変更されるとどうなりますか？変更された（Wikiは変更されないかもしれませんが、リソースは変更される可能性があります）か、タイプミスのためですか？私たちのリソースは非常に技術的で、長い言葉であり、間違いを起こしやすいものです。 また、数値であるデータベースIDがあります。仮装レンタルストアを使用して、ビデオのアドレスのアイデアを見てみましょう。 http://vidsyeah.com/video/sliding-doors/287171 IDは明らかであり、DBルックアップで使用されます。いいよ スライドドアビットは一意ではなく、ビデオタイトルから生成されただけで、GETで検証できます。したがって、スライドドアが入力され、doc 287171に実際にあるものと一致しない場合、404と応答します。 あるいは、誰かが気にかけた場合、人間が好きなものをそこに貼り付けることができるようにすることもできます。したがって、このURLも機能します。 http://vidsyeah.com/video/anything-at_all/287171 友好的な部分を検証する際の問題は、前述のように、名前の変更またはタイプミスの修正の問題です。名前が変更され、ドメイン内で実際に発生した場合、そこにあるURLを壊したくないので、次のようにします。 友好的な部分を確認しないでください。 確認しますが、以前のフレンドリIDが引き続き機能するように、フレンドリパーツの「履歴」をデータベースレコードに追加します。 あなたの考えやアイデアは大歓迎です。 ルカ

24 web-applications  rest  web  websites  http 

この記事の著者は、 時には、本質的にRESTfulではない操作をAPIで公開する必要があります。 そしてそれ APIのアクションが多すぎる場合は、RESTful原則を使用するのではなくRPCの観点で設計されているか、問題のAPIがRPCタイプモデルにより適していることを示しています。 これは、他の場所でも読んだり聞いたりしたことを反映しています。 しかし、これは非常に紛らわしいと思うので、問題をよりよく理解したいと思います。 例I：RESTインターフェースを介してVMをシャットダウンする VMのシャットダウンをモデル化するには、根本的に異なる2つの方法があると思います。それぞれの方法にはいくつかのバリエーションがありますが、ここでは最も基本的な違いに集中しましょう。 1.リソースの状態プロパティにパッチを適用します PATCH /api/virtualmachines/42 Content-Type:application/json { "state": "shutting down" } （または、PUTサブリソース上/api/virtualmachines/42/state。） VMはバックグラウンドでシャットダウンし、シャットダウンが成功するかどうかに応じて、後のある時点で状態が「電源オフ」で内部的に更新される可能性があります。 2.リソースのアクションプロパティのPUTまたはPOST PUT /api/virtualmachines/42/actions Content-Type:application/json { "type": "shutdown" } 結果は、最初の例とまったく同じです。状態はすぐに「シャットダウン」に更新され、最終的には「電源オフ」に更新されます。 どちらのデザインもRESTfulですか？ どちらのデザインが優れていますか？ 例II：CQRS 複数の集約の更新につながる可能性のある、または具体的なリソースとサブリソースのCRUD操作にマッピングできない「アクション」（別名コマンド）が多数あるCQRSドメインがある場合はどうなりますか？ 具体例で可能な限り多くのコマンドを具体的なリソースで作成または更新し（例Iの最初のアプローチに従って）、残りの部分に「アクションエンドポイント」を使用してみてください。 または、すべてのコマンドをアクションエンドポイントにマッピングする必要があります（例Iの2番目のアプローチのように）。 どこで線を引きますか？設計のRESTful性が低下するのはいつですか？ CQRSモデルは、APIのようなRPCにより適していますか？ 上記の引用テキストによると、私が理解しているとおりです。 私の多くの質問からわかるように、このトピックについて少し混乱しています。それをよりよく理解するのを手伝ってもらえますか？

24 rest  domain-driven-design  api-design  cqrs 

Odataのポイントと、それがいつ意味をなすかを理解しようとしています。今の私の仕事は、ASP.NETとMVC / WebApiコントローラーを使用してオブジェクトをJSONにシリアル化/逆シリアル化し、javascriptに何かをさせることです。 ODataの利点は、URLから直接クエリできることからわかりますが、クライアントコードとサーバーコードを記述しているので、その必要はありません。 誰かがjavascriptでODayaクエリの結果を解析することはありますか？ たぶん、ODataは、JSONが提供しないクエリから詳細な情報を取得するために、すべてのクライアントに汎用エンドポイントを提供することに関するものでしょうか？もし私がデータの提供者だったら、それがodataの目的だと思いますか？ REST / JSON / ODATAの目的と使用法を理解してください。

23 javascript  rest  json 

インターネットで一番かわいい猫をランク付けしている会社があるとしましょう。 /cats/ユーザーに最新のかわいい猫を提供するリソースを提供します。 ユーザーは、支払いを行っていないか登録していない場合、上位3匹の猫のみを取得できます。337ドルを支払ってログインしている場合は上位10匹の猫、1337ドルを支払ってログインしている場合は上位100匹の猫。リクエストを行うときに「ユーザーID」があります。 要するに、消費者は/cats/「ユーザーランキング」に基づいて異なる数の猫を取得します。消費側にはユーザー識別子がありますが、消費側にはユーザーレベルの明示的な表現はありません。リクエストを行うときにサブスクリプションをアップグレードできることをユーザーに通知したいと思います。つまり、3匹の猫と3匹の猫しか提供していないため、3匹の猫を区別する必要があります。これは、ユーザーレベルで許可されているためです。 消費者が十分な特権を持っていないためにリソースを制限し、それが制限されていることを区別するためのベストプラクティスは何ですか？ クライアントは、ランキングをアップグレードできるかどうかをどのように知っていますか？それはので、彼らは限られたリソースを持っている彼らは権限がありません。ここでのベストプラクティスは何ですか？ これは実際のケースを大幅に単純化したものであることに注意してください。また、単に明確にするために-読んでいただければ幸いです。 更新： 検討したオプションは次のとおりです。 クライアントに一度ユーザー権限オブジェクトを保存し、アカウントのログインまたはアップグレードが実行されたときにのみ照会します。 null存在することを示す値をJSONで渡しますが、実際には何も転送されませんでした。したがって、3匹の猫を持つユーザーの場合、10匹の猫は["Garfield","Sylvester","Puss in Boots",null*7] リソース許可ペアを渡す {cats:["Whiskers","Fluffy","Socks"],authCount:3} 一番かわいい猫を可能な限り最良の方法で配達するために、初めてこれを正しく行いたいと思います。

23 rest  http  url  http-response 

リソースを持つWebアプリケーションと、別の同様のリソースを持つリモートアプリケーションへの参照があるシステムを想定して、「ローカル」リソースを「リモート」リソースと同期する双方向同期アクションをどのように表現しますか？ 例： ToDoリストを表すAPIがあります。 GET / POST / PUT / DELETE / todos /など そのAPIは、リモートTODOサービスを参照できます。 GET / POST / PUT / DELETE / todo_services /など APIを介してプロキシ経由でリモートサービスから仕事を操作できます GET / POST / PUT / DELETE / todo_services / abc123 /など TodoのローカルセットとTODOSのリモートセット間で双方向の同期を行う機能が必要です。 ある種のRPCでは、次のことができます POST / todo_services / abc123 / sync / しかし、「動詞は悪い」という考えでは、このアクションを表現するより良い方法はありますか？

23 api  rest  api-design  synchronization 

私は実用的なREST APIを設計していますが、既存のエンティティをコレクションに追加する最善の方法に少し立ち往生しています。私のドメインモデルには、サイトのコレクションを持つプロジェクトが含まれています。これは厳密な多対多の関係であり、関係を明示的にモデル化するエンティティ（ProjectSiteなど）を作成する必要はありません。 私のAPIにより、消費者は既存のサイトをプロジェクトに追加できます。ハングアップしているのは、本当に必要なデータはProjectIdとSiteIdだけだということです。私の最初のアイデアは： 1. POST myapi/projects/{projectId}/sites/{siteId} しかし、私も考えました 2. POST myapi/projects/{projectId}/sites JSONコンテンツとして送信されるSiteエンティティを使用します。 オプション1はシンプルで機能しますが、あまり適切ではないため、このパターンに従うことができない他の関係があるため、APIに矛盾が生じます。 オプション2は良い感じですが、2つの懸念につながります。 新しいサイトが投稿された場​​合（SiteId = 0）、サイトを作成するか、例外をスローする必要がありますか？ 関係を作成するためにProjectIdとSiteIdのみが必要なため、他のプロパティのデータが間違っているか、欠落しているサイトが投稿される可能性があります。 3番目のオプションは、関係を作成および削除するためだけに単純なエンドポイントを提供することです。このエンドポイントでは、ProjectIdとSiteIdのみを含むJSONペイロードが必要です。 どう思いますか？

23 rest  api-design 

私の会社は現在、マイクロサービスアーキテクチャの採用に取り組んでいますが、その過程で成長中の痛み（衝撃！）に直面しています。私たちが直面している主要な競合ポイントの1つは、異なるサービス間で大量のデータを通信する方法です。 ちょっとした背景として、社内全体で処理する必要があるドキュメントのリポジトリとして機能するドキュメントストアがあります。このストアとのやり取りは、クライアントに一意のIDとドキュメントをストリーミングする場所を提供するサービスを介して行われます。ドキュメントの場所は、指定されたIDを使用したルックアップを介して後でアクセスできます。 問題はこれです-すべてのマイクロサービスが、ドキュメントとやり取りする目的のために、APIの一部としてこの一意のIDを受け入れることは理にかなっていますか？私にとってこれは本質的に間違っているように感じます-サービスはもはや独立しておらず、ドキュメントストアのサービスに依存しています。これによりAPIの設計が簡素化される可能性がありますが、おそらく、パフォーマンスを改善するだけでなく、結果として得られるカップリングの利点が相殺される可能性もあります。 レインボーユニコーン（Netflix、Amazon、Googleなど）がサービス間の大きなファイル/データ交換を処理する方法を知っている人はいますか？

22 design  rest  xml  microservices 

私は新しいビジネスWebアプリケーションを作成しています。 それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（単一ページアプリケーション）フレームワークが必要です。 さまざまなタイプのアプリケーション（たとえば、Webアプリケーション、モバイル（Android）、および場合によっては他のタイプ（スマートデバイスなど））から使用するバックエンドエンティティとビジネスサービスを公開します。 したがって、両方の要件を満たすために、バックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API（JSON）を使用してそれらの間の通信を整理する傾向があります。これは健全なアプローチですか？ 多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません（たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します）。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。 私が理解したように、完全に分離されたSPAフロントエンドは通常、サードパーティAPIを使用する必要性から生じます。しかし、バックエンドとフロントエンドの両方が1つの会社によって開発されたとき、そのようなデカップリングサウンドデザインはありますか？ 私が現在選択しているテクノロジーは、Java / Springバックエンドとフロントエンド用のAngular2 / Web Components / Polymerです。この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、それはこの質問とは無関係です。

21 design  rest  api  front-end  backend 

製品グループに製品のコレクションがあります。例： product-groups/123/products コレクションに追加する必要がある場合、PUTを使用して一部の製品のみを渡すことはできますか？ コレクションからいくつかの製品を削除する必要がある場合、フィルターデータ（IDの配列）をDELETEで渡しても大丈夫ですか？ ReSTの精神で機能を実装する最良の方法は何ですか？ 編集：アイテムは個別のエンティティ、基本的には製品のIDへのリンクです。

21 rest  collections