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

現在、次のような組織でプロジェクトに取り組んでいます。 クライアント -REST APIを介してメインサーバーからデータを取得します。 サーバー -サードパーティAPIを介して他のさまざまなサーバーからデータを要求します サードパーティ API-サーバーにデータを提供する私の制御できないサービス（Reddit、Hackernews、Quoraなど） 議論のために、クライアントが最初に各サードパーティAPIからのアイテムのリストを必要とするとしましょう。このリストからアイテムが選択されます。この時点で、クライアントはアイテムの完全なコンテンツとアイテムへの応答（コメント）を表示する必要があります。私は3つのオプションの間で決定しようとしています： アラカルト このアプローチでは、サーバーに3つのエンドポイントがあります。1つはアイテムのリストを取得し、1つはアイテムのメインコンテンツを取得し、もう1つはアイテムの応答を取得します。 長所：必要以上にリクエストを送信することはありません。リクエストは小さくなければならないので、一般的には高速になります。 短所：私は多くの要求をしなければなりません。リストから項目を選択した後、ユーザーはメインコンテンツを見る前に待たなければならない場合があり、それから応答を見るためにさらに長く待たなければならない場合があります サーバー側キャッシュ このリクエストでは、サーバーを1回呼び出して、すべてのソースのすべてのデータを「フェッチ」します。その後、データはサーバーにキャッシュされます。クライアントは以前と同じRESTエンドポイントを持つことになりますが、サーバーには既にデータがあり、それをクライアントにフィードするだけなので、呼び出しと呼び出しの間にあまり待つ必要はありません。 長所：クライアント側での実装は依然として簡単ですが、遅延の問題はありません 短所：サーバー側が少し複雑で、最初の呼び出しには本当に長い時間がかかる可能性があります。 クライアント側キャッシュ このシナリオは前のシナリオと似ていますが、クライアントがサーバーに対して1回だけ要求を行うという点が異なります。つまり、すべてのデータを提供します。ここから、データを保存して適切に使用するのはクライアントの責任です。 長所：簡単なサーバー実装、最初の呼び出し後は非常に高速 短所：最初の呼び出しは非常に遅く、より複雑なクライアント側の実装になります どちらが最善のアプローチであるのか、あるいは明らかな解決策が欠けているのかもしれません。どんなアドバイスも大歓迎です！

49 design  rest  api-design  server 

私はこれについて疑問に思っていました。 フィールドとフィールドを持つuserリソースがあるidとしnameます。フィールドを更新したい場合は、次のようにリソースに対してPATCHリクエストを行うことができます。 PATCH /users/42 {"name": "john doe"} そして、アプリケーションはユーザー42の名前を更新します。 しかし、なぜこのリクエストを繰り返した場合、結果が異なるのでしょうか？ よると、RFC 5789 PATCHは安全でもi等でもありません

48 rest  api-design  http  web-api 

最終的な処理のために長時間実行されるタスクをキューに入れることをサポートするRESTful APIを構築しています。 このAPIの一般的なワークフローは次のとおりです。 ユーザーがフォームに入力する クライアントがデータをAPIに投稿します APIは202 Acceptedを返します クライアントはユーザーをそのリクエストの一意のURLにリダイレクトします（/results/{request_id}） 〜最終的に〜 クライアントは再度URLにアクセスし、そのページで結果を確認します。 問題はステップ6にあります。ユーザーがページにアクセスするたびに、API（GET /api/results/{request_id}）にリクエストを提出します。理想的には、タスクは今までに完了しており、タスクの結果と共に200 OKを返します。 しかし、ユーザーは強引であり、結果がまだ処理を完了していないときに、多くの熱心な更新が期待されます。 次のことを示すステータスコードの最良の選択肢は何ですか？ このリクエストが存在する、 まだ終わっていない、 しかし、それも失敗していません。 単一のコードがすべてを通信することを期待していませんが、クライアントにコンテンツを期待させるのではなく、メタデータを渡すことができるものが欲しいのです。 202を返すことは理にかなっています。なぜなら、それはここでは他の意味を持たないからです。それはGET要求であるため、おそらく「受け入れられる」ものは何もありません。それは合理的な選択でしょうか？ これらすべてに対する明白な代替手段-機能するが、ステータスコードの1つの目的を無効にする-は、常にメタデータを含めることです。 200 OK { status: "complete", data: { foo: "123" } } ...または... 200 OK { status: "pending" } 次に、クライアント側で、リクエストが完了したかどうかを判断するためswitchに（ため息をつきます）response.data.status。 これは私がやるべきことですか？または、より良い代替手段はありますか？これは私にとってWeb 1.0だと感じています。

47 rest  http 

HTTP GETリクエストに応答して、REST API がサブオブジェクトで追加データを返すと仮定しますowner。 { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'Programmer' } } 明らかに、誰もがPUTバックアップできるようにしたくない { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'CEO' } } そしてそれを成功させます。確かに、この場合、おそらく潜在的に成功する方法さえ実装しないでしょう。 しかし、この質問はサブオブジェクトだけではありません。一般的に、PUTリクエストで変更できないデータを使用して何を行う必要がありますか？ PUTリクエストから欠落している必要がありますか？ 静かに捨てるべきですか？ チェックする必要があり、その属性の古い値と異なる場合、応答でHTTPエラーコードを返しますか？ または、JSON全体を送信するのではなく、RFC 6902 JSONパッチを使用する必要がありますか？

46 rest  http  http-request 

RESTの原則に従って、いくつかの基準を使用して検索を行い、結果をクライアントに返すAPIのGETメソッドを作成します。問題は、基準に最大14個のパラメーターを設定できることです。そのうちの1つは複雑なオブジェクトのリストです。 これらの複雑なオブジェクトをURLパラメータとの間でエンコード/デコードできるかどうかさえわかりません。 URLが取得できる時間は計算しませんでしたが、十分に大きく、URLの長さの制限に達すると確信していますか？ また、検索は結果を「リアルタイム」で表示する必要があります。つまり、ユーザーが検索フォームから何かを変更するたびに、「検索」ボタンを押さなくても新しい結果を表示できるはずです。 これらの点を明確にして、多くのパラメーターを使用して安らかな検索方法を作成することをお勧めしますか？

44 rest  api 

RESTサービスの仕様をまとめています。RESTサービスの一部には、サービス全体およびリソースのグループまたは個々のリソースでユーザーを調整する機能が組み込まれています。同様に、これらのタイムアウトは、リソース/グループ/サービスごとに構成できます。 HTTP 1.1仕様を調べて、クライアントが制限に達したために要求が満たされないことをクライアントに伝える方法を決定しようとしています。 最初は、クライアントコード403 - Forbiddenが1つであると考えましたが、これは仕様からです。 承認は役に立たず、リクエストは繰り返されるべきではありません 私を悩ませた。 実際に503 - Service Unavailableは、使用するほうが良いようです- Retry-Afterヘッダーを使用することで再試行時間の通信が可能になるためです。 将来的には、eコマースを介してより多くのリクエストを「購入」することをサポートする可能性があります（この場合、クライアントコード402 - Payment Requiredが確定されていればいいと思います！）。 私はどちらを使うべきだと思いますか？または、私が考慮していない別のものがありますか？

43 web-services  rest  http 

私は以前SignalR、いくつかのプロジェクトでリアルタイムのメッセージング機能を実現していました。確実に機能するようで、使い方を学ぶのは非常に簡単です。 少なくとも私にとっての誘惑は、Web APIサービスの開発を放棄し、SignalRすべてに使用することです。 思いやりのある設計によってこれを達成できると思います。もしそうなら、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなく、サービスへの単一のインターフェースがあることを意味し、最悪の場合、物事がいつレンダリングされるかなどを考えずにこれを接続できることを意味します。 だから、私は知りたい： パフォーマンス以外にすべてのWebサービスの代わりにSignalRを使用しない他の理由はありますか？ SignalRのパフォーマンスは、そうするのが理にかなわないということに関して十分ですか？ 馬鹿げたようなことをせずに、サーバー側のオブジェクトとサービスの定義をクライアント側のサービスアクセスコードに変換できることは、長い間私の夢でしたnode.js。たとえば、興味深いオブジェクトInterestingObjectとそのオブジェクトへのサービスを定義する場合、サービスへCRUDのInterestingObjectService標準のURLルートを定義できます-"/ {serviceName} / {methodName}"-しかし、アクセスするクライアントコードを記述する必要がありますサービス。オブジェクトは、サーバーとバックにクライアントから渡されようとしているので、する実際的な理由はありません持っているがクライアント側のコードでオブジェクトを明示的に定義します。また、CRUD操作を実行するルートを明示的に定義する必要はありません。このすべてを標準化する方法があるはずだと思うので、WinFormsまたはJavaを書いている場合と同じように、サービスへのアクセスがクライアントからサーバーへ、そして透過的に戻るという仮定の下でクライアントを書くことが可能ですアプレットまたはネイティブアプリ、またはあなたが持っているもの。 SignalRが従来のWebサービスの代わりに使用するのに十分であれば、これを実現するための実行可能な方法である可能性があります。SignalRには、既に説明したサービスのようにハブを機能させる機能が既に含まれているため、この機能すべてをすぐに反映できる共通ベース（CRUD）サービスを定義できます。そうすれば、ほとんどの場合、サービスへのアクセスを許可することができ、慣習によってアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます。 DOM。 私の編集を読んだ後、私はそれが少し無意味であるように感じるので、私が何を得ているかについて質問があるかどうか私に尋ねてください。基本的に、サービスへのアクセスは可能な限り透過的にする必要があります。

42 design-patterns  rest  web-api  websockets 

AS3アプリケーションとバックエンドとの通信方法を変更するプロセスを進めており、RESTシステムを実装して古いシステムを置き換えるプロセスを進めています。 悲しいことに、作業を開始した開発者は現在、長期の病気休暇中であり、私に引き継がれています。私は過去1週間かそこらでこれを使って作業しており、システムを理解していますが、心配していることが1つあります。関数の関数への受け渡しが多いようです。たとえば、サーバーへの呼び出しを行うクラスは、プロセスが完了してエラーが処理されたときにオブジェクトを呼び出して渡す関数を受け取ります。 それは恐ろしい練習であると感じる「悪い気持ち」を与えてくれます。そして、いくつかの理由を考えることができますが、システムにやり直しを提案する前に確認が必要です。この問題の経験がある人はいないだろうか？

40 object-oriented  object-oriented-design  rest 

RESTful APIの設計を進めています。特定のリソースに対してJSONとXMLを返したいことがわかっています。私はこのようなことをすると思っていました。 GET /api/something?param1=value1 Accept: application/xml (or application/json) ただし、次のように、誰かがこのために拡張機能を使用して投げ出しました： GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) これらのアプローチのトレードオフは何ですか？拡張機能が指定されていない場合はacceptヘッダーに依存するのが最善ですが、指定されている場合は拡張機能を優先しますか？そのアプローチには欠点がありますか？

40 architecture  web-services  rest  http 

このようなリソースがあるとします book: type: object properties: author: {type: string} isbn: {type: string} title: {type: string} books: type: array items: book したがって、誰かがGET本のリソースを作成すると、次のように返されます [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"}, {"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber of Secrets"}] 職場の誰かから、推奨されるRESTプラクティスは、常にJSONオブジェクトとして応答を返すことであると聞きました。つまり、スキーマbooksは次のようになります。 books: type: object properties: list: type: array items: …

40 rest  json 

私のアプリケーションでは、一部のユーザーは姓を教えてくれますが、他のユーザーは教えません。REST APIレスポンスでは、どのボディが優先されます： 「ヌル」値の場合： {"firstName": "Bob", "lastName": null} または、不足しているキー： {"firstName": "Bob"}

40 rest  api-design  json 

私は、多くの問題に苦しんでいる非常に貧弱に設計されたソフトウェアプロジェクトへの変更を提案しています。高レベルでは、プロジェクトはフロントエンドでAngularを利用し、さまざまなREST APIを使用します。それはすべて素晴らしいことです（私たちの技術やツールを変更する必要はありません）。問題は、コードベースがUIでサーバー側のAPIよりも不均衡に大きいことです。ビジネスロジックの多くはUIに存在し、REST APIはUIレイヤーへの単純なCRUDデータベースインターフェイスです。 たとえば、顧客へのPOSTは顧客レコードを作成し、PUTはその顧客を変更します。それ以上でもそれ以下でもありません。ただし、ビジネスロジックはそれよりも要求が厳しくなります。顧客を作成する一般的なプロセスは、1つのデータベースレコードを挿入するだけではありません。他の必要なテーブルにデータをプロビジョニングし、特定の検証と計算などを実行します。この動作のすべてをカプセル化する単一のPOST / PUT呼び出しを行い、消費クライアントの負荷を軽減します。 したがって、私の視点では、この包括的なオーケストレーションはUIではなくサーバー（フルコントロール、ログなど）上に存在する必要がありますが、1つの反論は、このアプローチはRESTfulではなくなるということです。したがって、既存の技術スタックを継続することを推奨するが、コードが属する場所で基本的なシフトを実装することが推奨される場合、このアプローチをどのように説明するのが最適かはわかりません。

37 rest  api-design  enterprise-architecture 

JSON APIに関しては、応答をフラット化し、ネストされたJSONオブジェクトを避けるのが良いでしょうか？ 例として、IMDbに似ているがビデオゲーム用のAPIがあるとします。いくつかのエンティティ、Game、Platform、ESRBRating、GamesとPlatformsをマップするGamePlatformMapがあります。 ID 1のゲームを取得する/ game / 1をリクエストすると、プラットフォームとesrbRatingがネストされたゲームオブジェクトを返します。 { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"id":1,"name":"Xbox"}, {"id":2,"name":"Playstation"} ], "esrbRating": { "id": 1, "code": "E", "name": "Everyone" } } JPA / Hibernateのようなものを使用している場合、FETCH.EAGERに設定されていれば自動的にこれを行うことがあります。 もう1つのオプションは、単にAPIを追加して、エンドポイントを追加することです。 その場合、/ game / 1が要求されると、ゲームオブジェクトのみが返されます。 { "id": 1, "title": "Game …

37 design  rest  api-design  json 

誰もが実際に何が何であるかを実際に理解していない場合でも、誰もがSOAを実行しています。だから彼らは間違っています。それを類推として使用して、RESTが何であるか（または少なくとも私はそう思う）を知っており、その一部を実行したいと考えています。しかし、私はそれを正しくしたい。 だから私の質問は、RESTを行う適切な方法は何ですか？

36 rest  soa  resources  implementations 

WebApiを使用してRESTful Webサービスを設計していますが、オブジェクトの更新/作成時にどのHTTP応答と応答本文を返すのか疑問に思っていました。 たとえば、POSTメソッドを使用してJSONをWebサービスに送信し、オブジェクトを作成できます。HTTPステータスをcreated（201）またはok（200）に設定し、「New Employee added」などのメッセージを返すか、元々送信されたオブジェクトを返すのがベストプラクティスですか？ 同じことがPUTメソッドにも当てはまります。どのHTTPステータスを使用するのが最適で、作成されたオブジェクトまたはメッセージだけを返す必要がありますか？とにかくユーザーが作成/更新しようとしているオブジェクトを知っているという事実を考慮してください。 何かご意見は？ 例： 新しい従業員を追加： POST /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Name" : "Joe Bloggs", "Department" : "Finance" } } 既存の従業員を更新します。 PUT /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Id" : 1 "Name" : "Joe Bloggs", "Department" : "IT" } …

36 rest  http