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

いくつかの統計情報を返すAPIエンドポイントがあります。現在、応答は次のようになります。 オプション1： { "stats": [ { "name": "some-stats-key1", "value": 10 }, { "name": "some-stats-key2", "value": 20 } ], ... other keys } しかし、これは少し複雑に見え、私はそれをどのようにするのか： オプション2： { "stats": { "some-stats-key1": 10, "some-stats-key2": 20 } ... other keys } オプション1は拡張が簡単ですが、ユーザーにとって快適ではないことを理解しています。これらのオプションのいずれかを使用して直面する可能性がある他の問題は何ですか？または、次のようなハイブリッドソリューションを作成する必要があります。 オプション3： { "stats": { "some-stats-key1": { "name": "some-stats-key1", "value": 10 }, "some-stats-key2": { …

9 rest  api  json 

現在、会社で使用するアプリケーションを計画しています。デスクトップアプリケーションをビルドするために必要です。現在のところ、近い将来、アプリケーションがモバイルまたはブラウザーで利用可能になるかどうかは不明です。 私には2つの可能性があります。 デスクトップアプリケーションから直接データベースにアクセスする REST APIを作成してこれに接続する アプリケーションが社内のデスクトップアプリケーションのみである場合、REST APIを使用できますか？それが可能であることは知っていますが、「正しい」方法ですか？（ベストプラクティス） REST APIを直接作成することには、いくつかの（可能な）利点と欠点があります。 短所： 開発に時間がかかる より複雑 サーバーはより多くの作業を行います セキュリティ上の問題 もっとゆっくり？（サーバーとデスクトップアプリケーションは同じネットワーク上にあります） 利点： 他のプラットフォームへの移行は簡単です ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません 複雑さについても同じ セキュリティ（コメントでtkauslが言及） 保守性（WindRavenによるコメントでの言及）

9 architecture  rest  api  desktop-application 

基本的に、私のアプリの1つの機能は、ログに記録されたユーザーの友達を取得することです。 実際、私は両方の種類のエンドポイントの間で迷っています： GET / api / users / friends GET / api / users /：userId / friends 1を使用userIdすると、認証トークンを通じて到達可能になります。 2を使用すると、サーバーは、渡さuserIdれたと、認証トークンで指定されたログに記録されたユーザーIDとの対応をさらにチェックして、友達などの他のユーザーデータへの悪意のあるアクセスを回避する必要があります。 したがって、1で十分ですが、標準のレストURLのようには聞こえません。 良い習慣とは何ですか？

9 rest  http  authentication  url 

PHP Codeigniter MVCデザインパターンを使用しています そして私はある種の特定のビジネスプロセスを備えたこのプロジェクトを持っていました 私のアプリケーションでは、2つの既存のREST APIを扱います。 グーグル トレロ ビジネスロジックレイヤー（BBL）として機能するREST APIを作成するというアイデアを思いつきました 次に、モデルに直接アクセスして、ビジネスルールを作成するために必要なデータをフェッチします。 RESTクライアントを使用してBLLと通信するコントローラー、 パフォーマンスの悪いアプローチですか？ データアクセスレイヤー（DAL）とビジネスロジックレイヤー（BLL）の2つのモデルのレイヤーを作成する方が良いですか？

9 php  design-patterns  mvc  rest  codeigniter 

RESTスタイルのWebインターフェースのフローチャート表現の作成に関する提案はありますか？共同開発者に完全なドキュメントを提供するために、製品リソースを変更および生成するためのインターフェースをモデリングするために、いじくり回してきました。 この特定のシステムは、ユーザー認証/リソース数によって異なる動作を開始するため、変更を加える前に、いくつかの明確化を探しています。 複雑さ：全体の構造を単純化してこれを読みやすくするにはどうすればよいですか？ 表示記号：これはページを表すのに適していますか？ 手動操作記号：これは、ボタンクリックなどのユーザーアクションを表すのに適していますか？ 他の提案は大歓迎です。 再投稿をお詫び申し上げます。メインのstackexchangeサイトは、この質問はプログラマーにより適切に提示されることを示唆しています。

9 documentation  rest  flowchart 

私はこの方法でこの質問をします-私のREST APIを「正しい」方法で実装しないことのソフトウェアエンジニアリングの懸念は何ですか？ 「正しい」方法とはどういう意味ですか？まあ、私が正しい方法についての私の認識を説明できるようにしてから、私がそれをどのように行っているかを説明します（また、JSON REST APIについて話していると仮定します）。 正しい方法 無国籍。これは私が得る部分です。クライアントは常に100％いつまでも状態を維持します。それはサーバーの仕事ではなく、クライアントの仕事です。 各動詞の予想されるアクションと応答： GET-完全に指定されたリソースを取得します。リクエストの承認またはクエリパラメータのいずれかによってのみ制限されます。これにより、プロセス内のリソースが変更されることはありません。 POST-リソースの説明全体（JSONオブジェクトなど）を指定すると、リソースを作成し、日付やIDなどのサーバー側のプロパティも作成してそのリソースを返します。 DELETE-指定されたリソースを削除し、応答として何らかの200 OKのみを与えます PUT -指定されたオブジェクト全体宣言入力として、入力で与えられたフィールドのそれぞれにリソースのすべてのフィールドを更新し、特定の場所でリソースを更新します。明確にするために、これはオブジェクト全体が入力として渡されることを期待しています。更新されたリソース全体が、すべてのフィールドとともに（許可またはその他の入力フラグに従って）返されます。 PATCH-リソースの変更が必要なフィールドのみを指定して、入力として指定された指定されたリソースのフィールドのみを更新します。（これは私が不明瞭なところです）：リソース全体が返されますか？（または、更新されたフィールドだけですか？Dunno。気にしないでください。） リソースパス。リソースの相互関係を考えると、リソースパスは次のいずれかになります。 / parentresource /：id / parentresource /：id / childresource / parentresource /：id / childresource /：childId / parentresource /：id / childresource /：childId / subresource /：subresourceId（この例では、サブリソースは、親リソースに属する子リソースに属しています）。 やりたいこと 上記は、REST APIがどのように機能するかについての私の理解です。次に、上記のバリエーションのいくつかをリストします。 PUT / PATCH-変更のためにリソース全体を渡すポイントは何ですか？リソースの変更にはPUTのみを使用し、更新するフィールドのみを渡します。その結果、パッチを使用する必要はありません リソースパス-アプリケーションでGUIDを使用しています。その結果、それらは世界的にユニークになります。単独でサブリソースを一意に参照できるのに、親リソースを含む完全なリソースパスが必要なのはなぜですか？以下のような： /サブリソース/：subresourceId ：もし私のような完全なパスが必要となるサブリソースを参照しようとし、それを「正しい」やり方をやっていた / parentresource …

8 design  rest  api  standards 

私と友達の間で議論を解決してください。 現在、製品APIを設計しています。製品エンティティは次のようになります { "Id": "", "ProductName": "", "StockQuantity": 0 } 製品の販売はサードパーティが処理し、StockQuantityフィールドを減らすことができるように購入数量を通知する義務があります。 私のアプローチ： PUT /api/Product/{Id}/ --data { "StockQuantity": "{NewStockQuantity}" } サードパーティは、製品のクエリ、現在のStockQuantity購入数量に基づく計算、およびPUT新しい値でのリクエストの送信を担当します。 私の友人はサードパーティに計算を望まない。彼のアプローチ PUT /api/Product/{Id}/DecreaseStock --data { "PurchasedQuantity": "{PurchasedQuantity}" } したがって、計算を行って、 StockQuantity 私は関数ベースのエンドポイントを作成したくありません、そして彼は計算を行うためにサードパーティを信頼したくありません。 この問題に取り組むための正しい方法は何でしょうか？

8 design  design-patterns  rest  api-design  rpc 

私はRest APIを開発していて、自分自身に質問しています。 たとえばファイルのアップロードのために、base64でエンコードされたデータをJsonに配置することは良い考えですか？何base64ではいくつかの含まれている場合は{、}、:文字や休憩JSONコンテンツを？ 良いアイデアではない場合、ベストプラクティスとして広く考えられている選択肢はどれですか。

8 rest  json  file-handling 

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。 エンドポイント： POST /register/ POST /login/ POST /logout/ POST /password/change/ 実装： POST /register/： リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。 サーバーアクション： 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。 JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。 応答：サーバーはJSONでアクセストークンと更新トークンを返します。 POST /login/： リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。 サーバーアクション： 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。 レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。 POST /logout/： 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。 サーバーアクション： 更新トークンデータベースをチェックして、更新トークンを検証します。 データベースから更新トークンを削除します。 注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。 POST /password/change/： リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。 サーバーアクション： アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。 データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。 リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。 質問： このアプローチは安全ですか？具体的には： HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？ 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？ クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？ リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

8 design  rest  api  security  authentication 

アカデミックタスク…最初に.html、さまざまな行政区分での選挙結果を示す一連の静的ファイルを生成するように指示されました。次に、Djangoテンプレートを使用してこれを「近代化」するように指示されました。十分に公正で、私はそのようなアプローチの利点を見ることができます。 しかし、アプリを「RESTful」にすることで、これをさらに「mordernize」するように言われました。私の知る限り、これはサーバーがクライアントにJSON形式の生データを送信することでリクエストに応答するAPIのみを公開できることを意味します。静的なHTML + CSS + JSサイトであるクライアントは、このJSONを受信し、JavaScriptを使用してブラウザー側で動的にWebページを構築する必要があります。 悲しいことにいくつかの講義を欠場したので、これが説明されたはずですが、そのようなアプローチの利点は誰にでも説明できますか？私は欠点しか見ることができないと言わなければならないので： JavaScriptが無効になっているユーザーは、ページを表示できません。 私が間違っている場合は修正してください。ただし、このようなサイトのコンテンツはGoogleでインデックスに登録することができません。 ユーザーが特定の部門の選挙結果をブックマークすることは不可能です。代わりに、サイドにアクセスするたびに、クリックして特定の部門の結果をJavaScriptに読み込ませる必要があります。または、これを行うSeleniumボットをデプロイします。 ブラウザのボタンを元に戻す/進む。

8 rest 

RESTful Webサービスを設計するとき、サーバー間でやり取りされる値の文字列のIDを機能するようにAPIを設計する必要がありますか？ 次に例を示します。ステータスと性別の属性を持つ従業員リソースがあるとします。データベースのステータスと性別、および個別のテーブル、つまり個別のドメインオブジェクトで、それぞれが独自の識別子を持ちます。 クライアントのリクエスト/ employee / 1としましょう。サーバーが次のようなものを返す可能性があります... ケース1： { "id": 1, "firstName": "Jane", "lastName": "Doe", "active": true, "gender": { "id": 1, "gender": "FEMALE" }, "status": { "id": 3, "status": "FULL_TIME" } } ケース2： { "id": 1, "firstName": "Jane", "lastName": "Doe", "active": true, "gender": "FEMALE", "status": "FULL_TIME" } ケース3： { "id": …

8 rest  api-design  json 

偽のREST APIを非難する彼自身の記事に関するロイフィールディングのコメントから： 真にRESTfulなAPIはハイパーテキストのように見えます。すべてのアドレス可能な情報単位は、明示的に（たとえば、リンクとID属性）または暗黙的に（たとえば、メディアタイプの定義と表現構造から派生）のいずれかでアドレスを伝達します。クエリ結果は、オブジェクト表現の配列ではなく、要約情報を含むリンクのリストで表されます（クエリはリソースの識別の代わりにはなりません）。 これは、たとえば、最近ログインした100人のユーザーのリストをクエリして、その名前と電子メールを表示する必要がある場合、最初GETに結果のリストをクエリする必要があることを意味します。リンク要素のリストであり、各リンクオブジェクトにはユーザーリソースのURIが含まれます。結果を表示するために必要なデータを実際に取得する前に、さらに 100のGETリクエスト（ユーザーリソースごとに1つ）を行う必要があります。 それは信じられないほど非効率的です。1つまたは2つの要求で必要なデータを取得するための本当にRESTfulな方法は他にありませんか？

8 rest  api  api-design 

ここでは、RESTful APIの認証と承認のメカニズムを扱う多くの質問がありますが、アプリケーションレベルで安全なサービスを実装する方法の詳細については触れていません。 たとえば、私のWebアプリケーション（Javaを念頭に置いていますが、これは実際にはすべてのバックエンドに当てはまります）に、APIのユーザーがユーザー名とパスワードでログインできる安全な認証システムがあるとします。ユーザーがリクエストを行うと、リクエスト処理パイプラインの任意の時点でgetAuthenticatedUser()、ユーザーがログインしていない場合はnullユーザー、またはログインしているユーザーを表すユーザードメインオブジェクトを返すメソッドを呼び出すことができます。 APIにより、認証されたユーザーはデータにアクセスできます。たとえば、GET /api/orders/はそのユーザーの注文リストを返します。同様に、GET to /api/tasks/{task_id}はその特定のタスクに関連するデータを返します。 ユーザーのアカウントに関連付けることができるいくつかの異なるドメインオブジェクトがあると仮定します（注文とタスクは2つの例であり、顧客、請求書などもある可能性があります）。認証されたユーザーだけが自分のオブジェクトに関するデータにアクセスできるようにしたいので、ユーザーがを呼び出すときは、ユーザーが/api/invoices/{invoice_id}そのリソースにアクセスすることを許可されていることを確認してから、サービスを提供します。 私の質問は、この承認の問題に対処するためのパターンや戦略は存在するのでしょうか。私が検討しているオプションの1つは、ヘルパーインターフェイス（つまりSecurityUtils.isUserAuthorized(user, object)）を作成することです。これは、リクエストの処理中に呼び出して、ユーザーがオブジェクトをフェッチすることを許可されていることを確認できます。これは、これらの呼び出しの多くでアプリケーションのエンドポイントコードを汚染するため、理想的ではありません。 Object someEndpoint(int objectId) { if (!SecurityUtils.isUserAuthorized(loggedInUser, objectDAO.get(objectId)) { throw new UnauthorizedException(); } ... } ...そして、少し面倒かもしれませんが、すべてのドメインタイプにこのメソッドを実装するという問題があります。これが唯一のオプションかもしれませんが、私はあなたの提案を聞いて興味があります！

8 java  rest  security  backend 

多くのアイテムを含む結果のページ間をユーザーが移動できるようにするために、ページトークンを使用する新しいAPIがますます増えていることを確認しています。ただし、APIデザイナーの観点からは、ユーザーがスキップしたいアイテムの数を指定できるようにする場合と比較して、トークンを使用する利点が何であるかは明確ではありません。 だからここに私の質問があります： 開始インデックスよりもページトークンを使用する利点は何ですか？ 大まかに言えば、一般的なページトークンの実装では、どのようにしてページを追跡するのでしょうか。すべての結果をキャッシュすると、かなり非効率になります。ある種のハッシュを使用できると思いますが、結果を再構築するために何がハッシュされるのかわかりません。 ありがとうございました

8 programming-practices  rest  api-design 

バックグラウンド： 現在、REST APIを構築する過程で、ノードw / expressを使用しており、モバイルアプリと最終的には（最新のブラウザーベースの）Webサイトによって消費されます。 私は、ユーザーが自分のリソースを変更することのみが許可されるように、ユーザーの更新/アクション要求を承認する最良の方法を特定しようとしています。アクションは準高頻度で発生するため、懸念事項です。 注：この使用例では、エンティティーの所有権を譲渡することはできません。 可能なソリューション： 解決策：reddisなどのサーバーセッションで各ユーザーのリソースのリストを保存および維持します。 懸念事項：サーバー側セッションの永続化には、複数のサーバーに合わせて拡張する独自の複雑さのセットがあります。これもRESTに違反しています。詳細については、do-sessions-really-violate-restfulnessをご覧ください。 解決策： ユーザーの更新/アクションクエリの前に読み取りクエリを実行します。IEは私にこのユーザーのアイテムを提供し、リストにある場合は更新を続行します。 懸念事項： ユーザーがリソースに代わって操作するたびに追加の読み取りのオーバーヘッド。 解決策： ユーザーIDをdbレイヤーに渡し、それを更新条件付きの一部にします。または、ファンシーを取得したい場合は、データバックエンドに応じて、そのリソースに対してPostgresの行レベルのセキュリティなどを使用します。 懸念事項： リソースがリクエストしているユーザーのものかどうかを確認するには、リクエストのライフサイクルの少し遅いようです。エラーは、データバックエンドからずっと上にスローされる必要があります。同じように、認証とロールベースの承認はリクエストのライフサイクルの最初に行われることが多いので、少しずれているかもしれません。実装は、データバックエンドにも依存します。また、データバックエンドにビジネスロジックを示します。 解決策： クライアント側で一種のセッションに署名しました。JWTまたは暗号化/署名されたCookieを使用します。基本的に、ユーザーのリソースIDのリストを含む信頼されたセッションを維持します。 懸念事項： クライアント側セッションのサイズ。不要な場合でも、すべてのリクエストで送信されるという事実。複数のアクティブなセッション/クライアントの可能性を導入すると、メンテナンスが非常に複雑になります。リソースが別のクライアントに追加されたときに、クライアント側の状態をどのように更新しますか。 解決策： リソースがフェッチされるときに、署名された更新トークン（JWT）またはURLをリソースとともにクライアントに渡します。リソースが更新/アクションされたときに期待します。署名されたトークンには、ユーザーIDとリソースIDが含まれ、これらに対して簡単に確認できます。 懸念事項： リソースの所有権を譲渡できる場合は複雑になりますが、私の場合は問題ありません。更新前の読み取りよりも複雑になります。ちょっと変？ 最終的な考え： 私は最後の解決策に傾いていますが、それが頻繁に発生することはないので、何か不足しているのではないかと思いますか？あるいは、私が知らないデザインパターンの一部かもしれません。

8 rest  session  authorization  large-scale-project