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

REST APIの設計方法に関するいくつかのチュートリアルに従ってきましたが、まだいくつかの大きな疑問符があります。これらのチュートリアルはすべて、比較的単純な階層のリソースを示しています。これらのチュートリアルで使用されている原則が、より複雑な階層にどのように適用されるかを知りたいのです。さらに、彼らは非常に高い/建築レベルにとどまります。永続層は言うまでもなく、関連するコードはほとんど表示されません。Gavin Kingが言ったように、私は特にデータベースのロード/パフォーマンスについて心配しています： 開発のすべての段階でデータベースに注意を払えば、労力を節約できます アプリケーションがのトレーニングを提供するとしますCompanies。Companies持っDepartmentsていOfficesます。Departments持っていEmployeesます。Employees持っているSkillsとCoursesし、特定のLevel特定のスキルのは、いくつかのコースのために署名することができるように要求されています。階層は次のとおりですが、 -Companies -Departments -Employees -PersonalInformation -Address -Skills (quasi-static data) -Levels (quasi-static data) -Courses -Address -Offices -Address パスは次のようになります。 companies/1/departments/1/employees/1/courses/1 companies/1/offices/1/employees/1/courses/1 リソースを取得する したがって、会社を返すときに、階層全体を返すことはできませんcompanies/1/departments/1/employees/1/courses/1+ companies/1/offices/../。部門または展開された部門へのリンクのリストを返す可能性があり、このレベルでも同じ決定を行う必要があります。部門の従業員または展開された従業員へのリンクのリストを返しますか？それは部門や従業員などの数に依存します。 質問1：私の考えは正しいですか。「階層をどこで切るか」は、私がしなければならない典型的なエンジニアリング上の決定ですか ここで、尋ねられたときGET companies/idに、部署のコレクションへのリンクのリストと展開されたオフィス情報を返すことにします。私の会社には多くのオフィスがないので、テーブルOfficesと一緒に参加するAddressesことは大したことではありません。応答の例： GET /companies/1 200 OK { "_links":{ "self" : { "href":"http://trainingprovider.com:8080/companies/1" }, "offices": [ { "href": "http://trainingprovider.com:8080/companies/1/offices/1"}, { "href": "http://trainingprovider.com:8080/companies/1/offices/2"}, { "href": …

8 java  database  rest  performance  hibernate 

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

8 rest  api  async 

AndroidアプリのREST APIを構築しようとしています。私が持っていると仮定usersして、テーブル(id, name, email)とsongsを持つテーブルを(id, song_name, album)、豊富なとして、それらの間の関連を参加しstreamsました(user_id, song_id, listen_count)。すべてのストリームの詳細を取得して、アプリにリストとして表示したい。リストには、曲名、アルバム名、ユーザー名、聴取数が表示されます。私は3つのもっともらしいオプションを見ます- GET/streamsすべてのリストフェッチsong_idsとをuser_ids。次に作るGETに/user/:idして/song/:id、ユーザーと曲の情報を取得するために、各ユーザと楽曲IDのために。 GET/streamsすべてのリストフェッチuser_idsとをsong_ids。次に、すべてのユーザーに関する情報を取得GETする/user?ids=<comma_separated_ids>ために1つ、すべての曲に関する情報を取得するGETためsong?ids=<comma_separated_ids>に1つ。 GET/streams1回の呼び出しですべてを取得します。何かのようなもの - [ { "user_id" : 10, "song_id" : 14, "listen_count" : 5, "user" : { "id" : 10, "name" : "bla", "email" : "bla", }, "song" : { "id" : 14, "name" : "blu", "album" : "blu" } }, …

8 rest 

いくつかの関連ドメインをカバーする主要なアプリケーションREST APIでは、リソースが属するビジネスドメインに基づいてリソースを「エリア」に分割する方が理にかなっていますか、それとも単一のモデルを維持する方が良いですか？ たとえば、「販売」と「在庫」のサブドメインがあります。システムのユーザーは通常、一度に1つのドメインのみを考慮しますが、例外が発生する可能性もあります。両方のドメインに存在する「アイテム」の概念があるため、「アイテム」リソースを2つの異なる方法で実装できます。 各ドメインの概念を表すさまざまなリソースがあり、各リソースは関連データのみを保持しています。 / sales / items /：id / inventory / items /：id すべてのコンテキストで使用されるすべてのデータを含む単一のリソースがあります。 / items /：id ドメインの1つだけに属するリソースもたくさんあります。 「地域」の長所 単一ドメインのみに関心があるユーザー向けのAPIを理解しやすくする リソースの実装が簡単（一度に読み取る/更新する項目が少ない） 特定のドメインごとにリソースをより特殊化/最適化できます より詳細なレベルでリソースへのアクセスを制御する機能 単一の統合モデルの長所 複数のドメインに属するコンセプトの重複リソースはありません ユーザーが複数のドメインで作業する必要がある場合は、すべてのニーズに対応する単一のAPIを使用するだけで済みます 上記のAPIパーティショニングは、APIコントラクトと実装の両方の複雑さを軽減する有効な方法ですか？私はそれがどこにも言及されているのを見たことがありません。 どちらかのアプローチを支持して決定を下すために検討する必要があるものは他にありますか？

8 architecture  rest  api-design 

私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどがあるシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つために非常に意味があると思います。 他のシステムで同じエンティティを作成するために、他の多くの（類似した）API呼び出しをトリガーする単一のAPI呼び出しがある多くのシナリオがあります。たとえば、エンティティ "user"の例： フロントエンドがREST APIを呼び出す：PUT ... / user 私が想定しているのは、上記のAPIをリッスンするコードが複数のREST PUT呼び出しを行って、ベンダーA /ユーザー、ベンダーB /ユーザー、ベンダーC /ユーザー、内部システムA /ユーザー、内部システムB /ユーザーなどを呼び出すことです。 このような： +-------------------+ +--------+ PUT +-----------+ CALL | Vendor A API | | | +-------> | user +--------> | | | | | +-----------+ +-------------------+ | | | | Front | PUT +--------++ PUT …

8 architecture  rest  api 

広告キャンペーンのトラッカーデータをリクエストできる広告配信プラットフォーム用のAPIを構築しています。多くの場合、キャンペーンは数億のリクエストを超えるため、テラバイトに相当するデータが大量に存在します。したがって、APIの利用者が一度に大量のデータをリクエストすること（リクエストがタイムアウトするなど）を防ぐ必要がありますが、それを行うためのベストプラクティスが何かはわかりません。 私がすでに特定したオプションは次のとおりです。 データのどのセクションが必要かを示す追加のパラメーターをリクエストに追加する データを切り捨て、どういうわけか、より具体的なフィルターを使用する必要があることをクライアントに伝えます HTTPステータスコード413で応答します（ただし、これは応答ではなく、大きなリクエスト本文のようです） ストリーミングAPIへの切り替え（TwitterのストリーミングAPIなど） しかし私の質問は、このような状況に対する標準的な実践/適切な対応は何ですか？ 注：DoS攻撃はパブリックAPIではないため、それほど心配する必要はありません。

8 database  rest  http  ajax  scalability 

データベースへのインターフェースを提供するREST APIの機械で読み取り可能な記述（WADL、Swagger、RAMLなど）があるとします。 私のユーザーは、基になるデータベースに関するクエリをSQLまたは同様のクエリ言語の形式で送信します。ただし、REST APIを介してのみ、データベースに直接アクセスすることはできません。 そのようなSQLクエリを特定のREST APIへの一連のリクエストに変換するシステムを（できれば記述から半自動で）構築するには、どのアプローチを選択しますか？ そのような問題をどのように表現しますか？役立つアルゴリズム、理論的フレームワーク、またはツールはありますか？ REST APIは以下をサポートします。 読み取り専用操作、つまりSELECTSQLクエリのみ XPartialプロジェクション（例/persons?fields=firstname,lastname） RSQL制約（別の例を/persons?query=firstname==John;department.code==42参照）。 テーブル間の一部の参照（外部キー）はREST APIでは属性として表されますが（Person.department上記の制約の例など）、一部の参照はサブリソース（例：）として表されます/persons/{userName}/projects。つまり、一部のクエリでは、RESTリクエストに関して回答される「計画」を考案する必要があります。 例：「チャックノリスのアクティブなプロジェクトの名前」のクエリは、次のように変換されます。 /persons?query=firstname==Chuck;lastname==Norris userName結果から得る /projects/{userName}?fields=name&query=state==ACTIVE

8 java  sql  rest  planning  translate 

私たちの製品は私たちのサービスに新しいプレーヤーを登録し、それをAzure（私たちは.NETを使用しています）でホストすることを選択しました。 これは私が書いている最初のREST WSであるため、それが確実な解決策であるかどうかについてフィードバックを得たいと思いました。 アプリについて知っておくべきいくつかの仮定： ユーザーは、ユーザーのパスワードを要求せずに、匿名でサービスにログインします 水平スケーリングを可能にするには、WSは完全にステートレスである必要があります サードパーティのスヌーピングを防ぐためにHTTPS（SSL）を使用して接続しています 編集： ネイティブiOS / Androidデバイスを対象としています 私たちの主な懸念は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです そして抽象的な認証プロセス： クライアントは単純なハッシュ（UDID：Timestamp）を作成し、タイムスタンプを使用して基本的なアルゴリズムで暗号化します（たとえば、秘密鍵はハッシュの2番目の文字ごとです） クライアントはサーバーにUDID、タイムスタンプ、ハッシュを送信します サーバーはハッシュを再構築し、ユーザーから送信された暗号化されたハッシュを復号化します 2つが等しい場合-実際にクライアントから送信されたことがわかります（悪意のある送信者からではないことを願っています） すべての入力/提案は素晴らしいでしょう-明らかに私がこの問題を処理しているのは初めてなので、私はそれを間違って設計したかもしれません。 ありがとう！ 2回目の更新： OAuthのセキュリティ仕様を読むと、クライアントとサーバーは秘密鍵を知っている必要があり、クライアントはユーザーのモバイルデバイス（ウェブアプリではなく）にローカルに保存されているため、私の質問に対する実際の回答はないようです。 OAuthセキュリティガイド（http://hueniverse.com/oauth/guide/security/）から： OAuthを実装する場合、対称または非対称の共有シークレットの制限を理解することが重要です。クライアントシークレット（またはプライベートキー）は、サーバーがクライアントの身元を確認するために使用されます。WebサーバーなどのWebベースのクライアントの場合、クライアントの秘密（または秘密鍵）の機密を保持することは比較的簡単です。 ただし、クライアントがデスクトップアプリケーション、モバイルアプリケーション、またはブラウザーアプレット（Flash、Java、Silverlight）やスクリプト（JavaScript）などの他のクライアント側ソフトウェアである場合、クライアントの資格情報をアプリケーションの各コピーに含める必要があります。 。これは、クライアントシークレット（またはプライベートキー）がアプリケーションと共に配布される必要があることを意味し、継承によってセキュリティが侵害されます。 これは、そのようなアプリケーション内でのOAuthの使用を妨げませんが、サーバーがそのようなパブリックシークレットで持つことができる信頼の量を制限します。シークレットは信頼できないため、サーバーはそのようなアプリケーションを不明なエンティティとして扱い、アプリケーションに関する統計の収集など、信頼のレベルを必要としないアクティビティに対してのみクライアントIDを使用する必要があります。一部のサーバーは、このようなアプリケーションを禁止したり、さまざまなプロトコルや拡張機能を提供したりすることがあります。ただし、現時点では、この制限に対する既知の解決策はありません。

8 security  web-services  rest  scalability  authentication 

多くの人が知っているように、最近のモバイル開発は急増しており、私がコーディングしているものに影響を与えていると思います。具体的には、モバイルアプリケーション向けのWebサービスの開発に興味があります。 RPCとRESTの2つのアーキテクチャが考えられます。私はRESTサービスとRPCサービスの両方を開発しましたが、RPCサービスは、特にPHPなどの言語でコーディングする方がはるかに簡単であることがわかりました。それに関する問題はスケーラビリティにあるようです-多くの手順が存在する場合、サーバー側は簡単に混乱する可能性があります。 一方、RESTははるかに構造化されているように見え、サーバー側での保守が比較的容易になりますが、データを複数のリソースに分割する可能性があり、モバイルアプリケーションには（複数の理由で）悪影響を及ぼします。 私が経験したことから、ほとんどの場合RPCは少し良いようです： クライアント側とサーバー側の両方が、使用可能な手順と実行される呼び出しの数を最小限に抑えることを懸念しています。 アーキテクチャのルールに従うことは、そうでなければ可能である最適化で対抗しません。 RESTやRPCについて誰かに説明してもらうことはあまり期待していません。Webはそれでいっぱいです。モバイルアプリの開発経験のある人に、サーバーサイドでこれら2つのアーキテクチャを使用することについての意見を表明してほしい。ヒントも歓迎します（だれがヒントを好きではないですか？）。

8 rest  mobile  server-side  rpc 

RESTfulな観点から、（StackExchangeのような）フォーラム投稿を賛成するアクションに最も適切なHTTPメソッドは何ですか？ 投票の場合はPOSTを、投票を取り消す場合はDELETEと言いますが、ユーザーはメッセージごとに1つの票を投じることしかできないため、投票はべき等演算と見なすことができるため、PUTも可能です。

8 rest  http  semantics 

この質問はこれに触発されました。SOAPを発明する最初の目標は何でしたか？古い種類のHTTPとRESTがあったときになぜ発明されたのですか？

8 rest  http  soap 

RESTサービスでは、すべての応答で一意のリクエストIDを送り返したいと思います。内部プロジェクトのデバッグに役立つだけでなく、将来サービスを使用する可能性のあるサードパーティにサポートを提供する場合にも役立ちます。 すべてのRESTリクエストがレスポンスボディになる必要があるわけではないため（多くの場合、低レベルのREST APIはステータスコードと説明のみを利用します）、このリクエストを送り返す必要があるため、レスポンスヘッダーを使用する必要があると判断しました。 ID。 可能であれば、途中でプロキシによって取り除かれる可能性が低い HTTP応答ヘッダーを使用するようにします。 多数のクライアントがモバイルデバイスであり、クライアントとサーバー間の「興味深い」ネットワークトポロジにバインドされているため、これは非常に重要です。 ただし、同じサービスが、自社のファイアウォール/プロキシを使用する他の企業にも販売される可能性があります。 このため、よく知られているヘッダーの代わりにカスタム応答ヘッダーを使用するという考えを根本的に覆いました。 私の現在の優勝既知のヘッダーはETagヘッダーですが、それはほぼ正しいですが、それは完全ではありません- ETagはリソース用であり、リクエストではありません（つまり、同じリソースに対する2つの別々のリクエストは合法的に同じを返しますETag）。さらに、それを使用すると、エンティティタグを他の目的で実行できないことを意味します。 誰か良いアイデアはありますか？ 更新 Pragmaヘッダーは使用されているように見えますが、Asp.Net WebAPI内での書き込みに問題があります。 SOに関する関連質問です。

8 web-services  rest  http 

私が取り組んでいるREST APIの場合、一貫したレイアウトでJSONを返したいです。 { "Data" : { "Id" : 123, "Email" : "charlie@somewhere.com" "Firstname" : "Charlie", "Surname" : "Brown", }, "Error" : null } ペイロードには常に「データ」と「エラー」が含まれ、どちらかがnullになる可能性があります。 私の質問は、「データ」と、実際には1つのオブジェクトしか返さないエンドポイントに関するものです。たとえばusers/current、現在認証されているユーザーを返すAPI があるとします。上記のようにそのユーザーを返したでしょう。「Data」という名前の単一のJSONオブジェクト。 ゼロ、1つ以上のオブジェクトを返す可能性のあるエンドポイントの場合、（もちろん） "Data"を配列にします。 { "Data" : [ { (first object) }, { (second object) } ], "Error" : null } 一貫性を保つために、「データ」は常に配列でなければならないという見方を聞いたことがあります。エンドポイントが論理的に1つのオブジェクト（またはnull）のみを返す場合でも。 他の人はどう思いますか？複数のオブジェクトが返されない場合は、「データ」と配列を作成する必要はないと思います。

8 api  rest  json 

HATEOAS APIでは、可能な状態遷移を表すリンクが返されます。適合クライアントはそれらのリンクを取得してたどるだけですが、不適合クライアントが提供されたリンクをたどるのではなくURIを構築している場合、返される最も適切なステータスコード/応答は何でしょうか？ 400は、応答本文のいくつかの情報と一緒に機能します-これは私たちが現在行っていることです 403リクエストが機能しない可能性があることを意味するため、間違っていると思いますが、将来的にリンクが使用可能になる可能性があります 404はもっともらしいようです-この時点ではリソースは存在しません 人々はどう思いますか？条件付き要求は古い応答（結果として412sなど）に基づいて要求を処理できることを知っていますが、これは少し異なる状況です。 更新： これらのタイプの無効な操作に対する正しい応答は404であることがわかりました。リクエストの構文が正しい場合、有効なリソースに送られますが、ビジネスルールに違反しています。次に、いくつかの不自然な例を示します。 クライアントが、互いに20％以内でなければならない2つの数値を提供できるとしましょう。 クライアントがいくつかの計算を経た数値を提供できるとしましょう。その結果は、提供された元の数値が正しくなかったことを示しています。 400はこれらの正しい応答ですか？

8 rest  api-design  hateoas 

RESTとGraphQLを比較する多くのサイトで見ました。「これは正しい比較ですか？」というこの懸念（実際には私の懸念）を調査した後、私はさらに混乱しています。RESTはGraphQLに対して異なる定義を持っているので、この質問は、2つの異なる概念を一緒に比較できるのはなぜか、と私の心を混乱させます。 実際には、比較は次のようなものだと私には思えます： IDE対コンパイラ！??！またはBMW x6 Vs ISO 18541-5（道路車両） ウィキから： 残りの定義： 表現状態転送（REST）は、Webサービスの作成に使用される一連の制約を定義するソフトウェアアーキテクチャスタイルです。 GraphQl定義： GraphQLは、API用のオープンソースのデータクエリと操作言語、および既存のデータでクエリを実行するためのランタイムです。 あなたの答えで私の心を明るくしてください。ありがとう

7 rest  comparison  graphql