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

私は、サードパーティのREST APIからデータをクエリする新しいプロジェクトに取り組んでいます。これはリアルタイムのスポーツデータフィード用であるため、フィードはゲームが実際に行われているときにのみ機能します。 サードパーティは優れたドキュメント（XSDなど）を提供しますが、ゲームの発生をシミュレートする方法がないため、このAPIに対して記述したコードをテストするには、実際のゲームが発生するのを待つ必要があります。 私の唯一の手段は、自分でゲームをシミュレートするコードを書くことですが、多くの作業のように思えます。これにどのようにアプローチしますか？

13 api  rest 

データ用にRESTful APIを完全に使用するJavaScript Webアプリケーションがあるとします。 このアプリケーションにはデータフォームがあり、/ product / 12345のレコードを編集しているとします。フォームを作成するとき、/ product / 12345にRESTfulリクエストを行い、JSONデータを取得します。 { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27 } したがって、私のフォームには、営業担当者を選択するためのドロップダウンリストがあるのは明らかです。このリストを作成する必要があります。 データはどこから取得する必要がありますか？最も一般的なアプローチは何ですか？ / product / 12345要求応答の一部にすることは理にかなっていますか？ { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27, "sales_users": [ {"id": 1, "name": "Anna Graham"}, {"id": 2, "name": "Dick Mussell"}, {"id": …

13 api  rest  forms 

そのため、RESTfulサービスの語彙には動詞の固定セットがあります。RESTful Webサービスは、HTTPメソッドからこれらを取得します。固定語彙を定義することにはいくつかの利点があると思われますが、私はその点を本当に理解していません。たぶん誰かがそれを説明できるでしょう。 RESTで概説されている固定語彙が、各状態の語彙を動的に定義するよりも優れているのはなぜですか？たとえば、オブジェクト指向プログラミングは一般的なパラダイムです。RPCは固定インターフェースを定義するために記述されていますが、なぜ人々はRPCがこれらの制約によって制限されていると仮定するのか分かりません。RESTfulサービスがそのコンテンツ構造を動的に記述するように、インターフェイスを動的に指定できます。 RESTは、語彙を増やすことなく成長できるという点で有利であると考えられています。RESTfulサービスは、リソースを追加することで動的に成長します。オブジェクトごとの語彙を動的に指定してサービスを拡張することの何がそんなに悪いのでしょうか？オブジェクトでボキャブラリーとして定義されているメソッドを使用し、これらのメソッドが何であり、副作用があるかどうかをクライアントにサービスで説明させてみませんか？ 基本的に、サーバー側のリソース構造の記述は語彙の定義と同等であると感じますが、これらのリソースとやり取りするために限られた語彙を使用せざるを得ません。 固定語彙は、クライアントの懸念をサーバーの懸念から本当に切り離しますか？確かにサーバーの構成に注意する必要があります。これは通常、RESTfulサービスのリソースの場所です。動的ボキャブラリーの使用に不満を言うことは、とにかく何らかの方法でこの構成を理解する方法を動的に推論する必要があるため、不公平に思えます。RESTfulサービスは、ハイパーメディアを介してオブジェクト構造を識別することによって実行できる遷移を記述します。 固定語彙が、自己記述型の動的語彙よりも優れている理由がわかりません。これは、RPCのようなサービスで簡単にうまく機能する可能性があります。これは、HTTPプロトコルの語彙が制限されていることの不十分な理由にすぎませんか？ 反射 私の考えを私がやったよりも少し良くするためだけに。おそらく汎用のAPIを設計していると仮定します。Web向けではないかもしれません。オブジェクトでこれらのメソッド名しか使用できないと誰かが言ったら、あなたは幸せになりますか？RESTはHTTPに限定されるものではありませんが、作成するすべてのAPI、Web向け、または単純にGET POST PUTおよびDELETEメソッドを含むオブジェクトで構成される状況を考慮してください。そのため、定義したいobject.fooメソッドは不可能です。fooという新しいオブジェクトを定義し、そのGETメソッドを呼び出す必要があります。それが本質的にRESTの仕組みであり、それについて考えるのが少し不快になります。fooが何をするかについての一般的な理解はありません。基本的には親オブジェクトのメソッドである新しいオブジェクトを作成するように強制されました。さらに、APIはそれほど複雑ではありません。より多くのオブジェクトを作成することにより、インターフェイスの複雑さが隠されているだけです。RESTful Webサービスでは、公開しているAPIのコンテキストでは十分である場合とそうでない場合があります。おそらく、Webに面したAPIでこれを行う正当な理由があるかもしれませんが、すべての汎用APIのすべてのオブジェクトに標準インターフェースを採用しない正当な理由があります。実用的な例に感謝します。

13 web-services  rest 

この素晴らしい記事http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/を参照してください。これは、WebサービスのAmazonのようなセキュリティについて述べています。ただし、既にHTTPSを使用している場合、なぜ必要なのかという質問がチームにありました。私は答えることができませんでした。実際のところ、彼らは正しいかもしれませんが、ガットはそうではないと教えてくれます。 RESTサービスを提供するときにHTTPSが機能しない場所もありますか？サードパーティのウェブサイトが好きですか？ パブリックインターウェブ経由でWebサービスをセキュリティで保護した経験がある人は、あなたの経験に光を当ててください。 前もって感謝します。 編集：明確にするために、私はユーザー認証ではなく、クライアント認証について話します。ユーザー認証は、HTTPS + RESTを介したプレーンテキストであると想定できます。 私の心配は、HTTPSを介してクライアントエンドポイントがクライアントアプリケーションなしでWebサービスを使用できるにもかかわらず、すべてがプレーンテキストであるため、クライアントがアクセスせずに誰でもWebサービスを使用できることです。

13 rest 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 Javaで書かれた大規模なユーザー向けWebサイトの開発に興味があります。 設計に関しては、メインのWebアプリケーションに対するデータプロバイダーとして機能できる、独立したモジュラーサービスの開発を考えています。 これらのモジュラーサービス（データプロバイダー）の作成については、Springなどの既存のフレームワークを活用し、RESTfulデザインパターンに従ってこれらのサービスを開発し、JSONなどのメッセージ形式でHTTPを介してリソースを公開するか、既存のネットワークを活用できますNetty（http://netty.io/）のようなフレームワークとProtobufs（https://developers.google.com/protocol-buffers/docs/overview）のようなシリアル化形式、およびシリアル化されたprotobuf を送受信するTCPサーバーを開発するペイロード。 どちらを選択するかはいつですか？Protobufsのようなシリアル化形式を使用して、ワイヤを介してバイトストリームを送信する利点はありますか？JSONを使用するだけでオーバーヘッドが発生しますか？TCP / IPを使用してからHTTPを使用するまでのオーバーヘッドはどれくらいですか？そのようなサービスを構築するためにSpring over Nettyをいつ使用する必要がありますか？

13 java  rest  http  serialization  tcp 

私はRESTful Webサービスの設計に関する研究を行ってきましたが、重要な決定点と思われるものに到達したため、アドバイスを得るためにコミュニティに提供すると思いました。 RESTfulアーキテクチャの原則に沿って、発見可能なAPIを提示したいので、さまざまなHTTP動詞を可能な限り完全にサポートします。私の難しさは、これらのリソースの表現の選択にあります。ご覧のとおり、検索結果の表示方法や他のリソースへのリンクの提供方法を​​カバーする独自のAPIを思い付くのは簡単ですが、これは私のアプリケーションに固有のものです。 Atom Publishing Protocol（RFC 5023）、およびODataがその使用を促進する方法について読んだことがありますが、（現在の）かなり単純なAPIに対して抽象化のレベルを追加するようです。 だから私の質問は、開発者が表現の選択としてAtomPubを選択する必要があるのはいつですか？そうでない場合、現在推奨されているアプローチは何ですか？

13 web-services  rest  api-design 

既に5回前後に切り替えました。このRESTエンドポイントは/api/tags/内部で使用するものであり（サードパーティのクライアントはありません）、私がそれを使用しているのは私だけです。 私はこれらの2つの表現の間で決定しています： 平らな { "types":[ { "id":1, "text":"Utility" }, { "id":7, "text":"Lease Terms" }, ], "tags":[ { "id":8, "text":"Water", "type":1 }, { "id":9, "text":"Electricity", "type":1 }, { "id":5, "text":"Minimum 12 month lease", "type":7 }, { "id":17, "text":"lease negotiable/flexible", "type":7 }, ] } ややモジュール化されています。互換性を損なうことなく、「国」などの別の最上位レイヤーを追加できます。 入れ子 { "1":{ "text":"Utility", "tags":{ "8":{ "text":"Water" …

12 rest  api-design  json 

私はRESTful APIを設計していますが、タイトルの問題に直面しました。 クライアントが認識されないパラメーターを送信した場合、高速で失敗する必要がありますか？例えば、 http://example.com/api/foo?bar=true&paula=bean 上記でbarは、は有効なパラメーターですがpaula、APIによって指定されていません。したほうがいい クライアントにエラーを警告する 早く失敗する それを無視します クライアントに警告する場合、最初のパラメーターに対して警告を発行できるのは、ほぼ無限の数のパラメーターを送信している可能性があり、サーバーにはおそらくより良いことがあるからです。同様に、失敗すると、最初の無効なパラメータのみが問題として指定されます。 警告を出すよりもプログラマーに強制的に行動を起こさせるよりも失敗を好む。そうでなければプログラマーは問題を無視してリソースを浪費し続けるかもしれない。その点で何もしないのはさらに悪いことです。 私の議論は理にかなっていますか？そのようなことに関して受け入れられている慣行はありますか？

12 rest  api-design 

特に、JavaScriptを介してHTML5フロントエンドで使用されるREST APIを開発しています。このアプリケーションは組織内で使用するためのもので、通常は約300人のユーザーがいますが、1000ユーザー程度までスケールアップしたいと考えています。 通常、APIへの接続はLAN内で行われるため、接続の品質と遅延は良好になりますが、3G / 4Gを介した接続が遅く、遅延が発生する可能性のあるインターネットでの時折の使用は除外されません。 私たちが考えた2つのオプションは次のとおりです。 フロントエンドは、APIに対して複数の非同期呼び出しを同時に行い、インターフェイスのさまざまなコンポーネントをロードします。 長所：シンプル。 短所：サーバーへの接続が増えます。 フロントエンドのコントローラーは、オブジェクトを取得する必要があるパラメーターとして渡すAPIを1回呼び出します。 長所：サーバーへの接続は1つだけですが、サーバーはデータベースに複数の接続を作成します。 短所：フロントエンドとAPIの両方のメカニズムが必要です。設計が複雑になります。 詳細な説明：さまざまなリソース... / Product ... / Locationsなどがあります。これらのリソースは単独で取得できますが、別の抽象的なリソース... / screen？Product＆Locationsが1回の呼び出しで両方を取得します。

12 rest  api  ajax 

RESTful URIに名前を付けるとき、リソースのコレクションを表すために複数形を使用することは一般に受け入れられていることを理解しています。代わりに単数名詞を使用するための引数について興味があります。

12 api  rest  uri 

以前にRESTful APIを作成したことはありませんが、RESTful APIをどの程度分離すべきか疑問に思っていますか？ たとえば、名前、住所、電話番号、メールアドレス、言語などを持っている顧客がいるとしましょう。 個々のフィールドを更新する方法（アドレスの更新、電子メールアドレスの更新など）があるのは理にかなっていますか、それとも顧客全体に対して単一の更新があり、各フィールドはオプションですか？

12 api  rest 

私はHTTP APIの設計を進めており、できればできるだけRESTfulにするようにしています。 機能がいくつかのリソースに広がるアクションがいくつかあり、いつか元に戻す必要があります。 これはコマンドパターンのように思えますが、どのようにリソースにモデル化できますか？ DepositActionのようなXXActionという名前の新しいリソースを紹介します。 POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... これにより、実際に新しいDepositActionが作成され、そのDo / Executeメソッドがアクティブになります。この場合、201 Created HTTPステータスを返すことは、アクションが正常に実行されたことを意味します。 後でクライアントができるアクションの詳細を確認したい場合 GET /action/{action-id} Update / PUTはここでは関係ないため、ブロックする必要があります。 そして、アクションを元に戻すために、私は DELETE /action/{action-id} 実際に関連オブジェクトのUndoメソッドを呼び出し、そのステータスを変更します。 やり直しが1回だけで満足だとしましょう。やり直す必要はありません。 このアプローチは大丈夫ですか？ 落とし穴、それを使用しない理由はありますか？ これはクライアントのPOVから理解されていますか？

12 design-patterns  api  rest  api-design  http 

RESTサービスとさまざまなクライアント（Silverlight、iOS、Windows Phone 7など）で構成される分散アプリケーションを設計しています。WCF Data Services（OData）を使用してRESTサービスを実装することを決定する準備ができていましたが、MVC 4 Web APIによってその決定に疑問が生じました。 ODataで気に入ったのは、無料で入手できるURIクエリ機能とハイパーメディア機能です。私が嫌いなのは、ODataペイロードの冗長性です。多くの不要なキャラクターがネットワーク上に来ます。 私がWeb APIで気に入っているのは、ペイロードがはるかに簡潔であり、ODataのURIクエリ機能を備えていることですが、ハイパーメディアが欠けているようです（少なくとも、箱から出して）。私の上司もWeb APIを推し進めています。「Microsoftの力がそれを後押ししており、ODataが勢いを増していないからです」。 そこで、2つの質問があります。 1）誰でもWeb APIとODataのバッキング/トラクションについてコメントできますか？ 2）Web APIは、リリース時間までにハイパーメディアをネイティブにサポートすることを期待されていますか、または検討すべき市販の実装または例がありますか？ ありがとう！

12 rest  asp.net-mvc-4 

ユーザーが意図した不正行為（軽度に言えば）に対する保護を追加すると、ユーザーが被る可能性のある害がコードに関連していない場合、過剰なエンジニアリングになりますか？ 明確にするために、次のような単純なJSON RESTfulサービスを公開しています。 GET /items - to retrieve list of user's items PUT /items/id - to modify an item POST /items - to add a new item サービス自体はブラウザで使用するためのものではなく、ユーザーが制御するサードパーティ製アプリケーション（電話アプリ、デスクトップアプリなど）からのみ使用するものです。また、サービス自体はステートレス（つまり、セッションレス）でなければなりません。 認証は、SSL経由の基本認証で行われます。 私は、次のような1つの可能な「有害な」動作について話しています。 ユーザーはブラウザにGET URLを入力します（理由はありませんが...）。ブラウザは基本認証を要求し、それを処理し、現在のブラウジングセッションの認証を保存します。ブラウザを閉じずに、ユーザーは悪意のあるWebサイトにアクセスします。このWebサイトには、サービスへのPOSTを作成する悪意のあるCSRF / XSRF javascriptがあります。 上記のシナリオは非常にまれであり、ビジネスの観点からはあまり心配するべきではないことを知っています。しかし、状況を改善するために、JSON POSTデータでもユーザー名/パスワードが必要な場合に役立つと思いますか？ または、基本認証を完全に削除し、GETを削除して、認証情報を含むPOST / PUTのみを使用する必要がありますか？GETを介して取得された情報は機密性が高い場合もあります。 一方、カスタムヘッダーの使用は純粋なREST実装と見なされますか？基本認証を削除し、カスタムヘッダーを使用できます。そうすれば、少なくともブラウザーからのCSRF攻撃を回避でき、サービスを使用するアプリケーションはカスタムヘザーでユーザー名/パスワードを設定します。このアプローチの欠点は、ブラウザからサービスを使用できないことです。

12 rest  authentication 

新しいRESTful Webサービスを設定していますが、役割ベースのアクセス制御モデルを提供する必要があります。ユーザーがユーザー名とパスワードを入力してサービスにアクセスできるようにするアーキテクチャを作成し、役割に基づいてサービスの使用方法（使用できるサービス、読み取りvs読み取り/書き込みなど）を制限する必要がありますそのユーザーに割り当てられます。 私は他の質問を見て回り、欲しいものを見つけました。たとえば、資格情報をRESTサービスのrestful-authenticationに渡す方法、ベストプラクティスを扱う方法については、いくつかの素晴らしい議論があります。また、プログラマーがWebサイトを作成するときに知っておくべきこと（すべての開発者が公開Webサイトを構築する前に知っておくべきこと）についての優れた指針もあります。 しかし、これらのソリューションを実装するソフトウェアアーキテクチャのベストプラクティスとパターンに関する優れた投稿、記事、書籍を見つけることができませんでした。 具体的には： ユーザーの詳細とアクセス権はどのように保存する必要がありますか？（データモデル、場所、形式） サーバーでこれらを表現および追跡するための優れた設計パターンは何ですか？（メモリ内のセッション、毎回のデータベース検索など） コードベースでこれらの権利を安全な方法でサービスにマッピングするための良いパターンは何ですか？ システムをより安全で信頼性の高いものに保つのに役立つアーキテクチャの選択肢は何ですか？ トレンチから学んだことは何ですか？ 特定の技術以外のソフトウェアアーキテクチャの設計パターンと推奨事項を探しています。 （テクノロジーが重要な場合は、python、twisted、およびpostgresqlデータベースを使用してこれを実装する予定です）

12 web-development  design-patterns  security  web-services  rest