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

RESTバックエンドとHTML + JSフロントエンドを搭載した新しいWebアプリケーションを設計しています。 1つのエンティティを変更するためのPOSTメソッドが1つあり（Configを呼び出しましょう）、アプリケーションの多くの要素の状態にいくつかの副作用があります。POSTが次のように実行されると仮定します。 POST /api/config BODY {config: ....} このため、これらの変更が行われる前にプレビューを表示して、エンドユーザーが何が変更されるかを確認できるようにします。 私が最初に考えたのは、プレビューのGETエンドポイントを作成して、エンティティの新しい状態の本体を送信することです。こちらです： GET /api/preview/items BODY {config: ....} 新しい構成のアイテムの新しい状態が表示される場合があります。 GET /api/preview/sales BODY {config: ....} 新しい構成での販売の新しい状態が表示される場合があります。 アプリケーションの状態を変更しないので、GET動詞を使用することをお勧めします。ただし、GET要求での要求本体の使用は推奨されないようです。 これについて良い習慣はありますか？他の選択肢として、1つの方法で構成をドラフトとして保存し、他の方法で結果を表示することもできますが、追加の手順が必要で、サーバーでドラフトを管理する必要があります。 POST /api/preview/config BODY {config: ....} GET /api/preview/items?idPreviewConfig=1

17 programming-practices  rest  http 

ユーザー認証にJWTトークンを使用するRESTful APIを構築しています（loginエンドポイントによって発行され、その後すべてのヘッダーで送信されます）。一定時間後にトークンを更新する必要がありrenewます（エンドポイントを呼び出して、更新されたトークンを返します） ）。 トークンの有効期限が切れる前にユーザーのAPIセッションが無効になる可能性があるため、エンドポイントはすべて、1）トークンがまだ有効で、2）ユーザーのセッションがまだ有効であることを確認することから開始します。クライアントがトークンをローカルに保存するため、トークンを直接無効にする方法はありません。 したがって、すべてのエンドポイントは、クライアントに次の2つの条件を通知する必要があります。1）トークンを更新する時間、または2）セッションが無効になり、システムへのアクセスが許可されなくなったこと。2つの条件のいずれかが発生したときにクライアントに信号を送るエンドポイントの2つの代替案を考えることができます（クライアントがいずれかのオプションに適応できると仮定します）： セッションが無効になった場合はHTTP 401コード（無許可）を返し、トークンの有効期限が切れてrenewエンドポイントを呼び出すときは412コード（前提条件失敗）を返します。これにより200（ok）コードが返されます。 セッションが無効であるか、トークンの有効期限が切れていることを通知するために401を返します。この場合、クライアントはすぐにrenewエンドポイントを呼び出し、200を返すとトークンが更新されますが、renew401も返す場合は、クライアントがシステム外にあることを意味します。 上記の2つの選択肢のうち、どちらをお勧めしますか？どちらがより標準的で、理解しやすく、そして/またはよりRESTfulでしょうか？または、まったく別のアプローチをお勧めしますか？どちらのオプションにも明らかな問題やセキュリティ上のリスクがありますか？回答にあなたの意見を裏付ける外部参照が含まれている場合の追加ポイント。 更新 皆さん、本当の質問に焦点を合わせてください- 更新/セッションの無効化を通知するための2つのHTTPコードの選択肢のうち、どちらが最適ですか？私のシステムがJWT とサーバーサイドセッションを使用しているという事実を気にしないでください、それは非常に特定のビジネスルールのための私のAPIの特性であり、私が助けを求めている部分ではありません;）

17 design  rest  web-services  http  authentication 

アプリケーションがWebSocketライブフィード用に既に開かれている場合、AJAXサーバーとのその他の通信にそれを使用する必要がありますか？ 接続はすでに開かれているので、Request/Responseリアルタイムではなく、リアルタイムのリクエストに使用する必要がありますか？ RESTful HTTPリクエストのほうがデバッグが簡単だと思うので、リクエストを好む ブラウザでURLまたはカールを使用して、APIが返すものをテストできます。を開くためにコードを記述する必要はありませんWebSocket。 同じアプリケーションにRESTful HTTP APIあるのWebSocketは奇妙でしょうか？

17 rest  ajax  websockets 

Event Sourcingの設計に出会い、RESTクライアントが必要なアプリケーションで使用したいと思います（正確にはRESTfulです）。ただし、RESTは非常にCRUDに似ており、イベントソーシングはタスクベースであるため、これらを接続することはできません。RESTサーバーへの要求に基づいてコマンドの作成をどのように設計できるのか疑問に思いました。この例を考えてみましょう： RESTを使用すると、Fileというリソースに新しい状態を設定できます。1つのリクエストで、新しいファイル名を送信したり、親フォルダーを変更したり、ファイルの所有者を変更したりできます。 イベントソーシングを使用できるようにサーバーを構築する方法。私はこれらの可能性について考えていました： フィールドが変更されたサーバ上で決定し、適切なコマンドを作成する（RenameFileCommand、MoveFileCommand、ChangeOwnerCommand、...）と個別にこれらを派遣。ただし、このセットアップでは、各コマンドが失敗し、他のリソースがトランザクションから除外され、リソースへの「アトミックな」変更から除外されます。 発送のみ一つのコマンド（UpdateFileCommand）およびコマンドハンドラでは、より正確に集計では、変更されたフィールドを決定し、代わりに個々のイベントを送信します（FileRenamedEvent、FileMovedEvent、OwnerChangedEvent、...） これはまったく好きではありません：サーバーへのリクエストでは、ヘッダーで使用するコマンドを指定します。UIはまだタスクベースです（ただし、通信はRESTを介して行われます）。ただし、REST通信のその他の使用（外部アプリなど）では失敗します。1つのリクエストで1つのフィールドのみを変更するようにバインドされているためです。また、UI、REST、およびESベースのバックエンドに非常に大きなカップリングをもたらします。 あなたはどちらを好むでしょうか、これを処理するより良い方法はありますか？ サイドノート：イベントソースのためにJavaとAxon Frameworkで書かれたアプリ。

17 design  rest  event-sourcing 

APIがクライアントの認証を必要とする場合、2つの異なるシナリオが使用されているのを見て、状況に応じてどのケースを使用すべきか疑問に思っています。 例1.サードパーティがHTTP Basicを使用してトークンとシークレットで認証できるようにするために、会社がAPIを提供しています。 例2. APIは、エンドユーザーを認証するためにHTTP Basicを介してユーザー名とパスワードを受け入れます。通常、彼らは将来のリクエストのためにトークンを受け取ります。 私のセットアップ：モバイルアプリおよびWebアプリのバックエンドとして使用するJSON APIを用意します。モバイルアプリとウェブアプリの両方がトークンとシークレットを一緒に送信することをお勧めするので、これら2つのアプリのみが他のサードパーティをブロックするAPIにアクセスできます。 ただし、モバイルアプリとWebアプリでは、ユーザーがログインして投稿を送信したり、データを表示したりすることができます。したがって、各リクエストでHTTP Basicを介してログインすることもできます。 これらの両方の方法を何らかの方法で組み合わせて使用​​するのですか、それとも各要求でエンドユーザーの資格情報（ユーザー名とトークン）のみを送信するのですか？エンドユーザー資格情報のみを送信する場合、クライアントのCookieに保存しますか？

17 api  rest  authentication 

（人間がAPIを直接参照するのとは対照的に）プログラムによる使用を目的としたAPIのHATEOASの利点を理解していません。確かに、顧客はURLスキーマにバインドされていませんが、私の考えでは同じデータスキーマにバインドされています。 たとえば、注文のアイテムを表示する場合、注文のURLをすでに発見または知っていると仮定します。 HATEOAS： order = get(orderURL); item = get(order.itemURL[5]); 非HATEOAS： order = get(orderURL); item = get(getItemURL(order,5)); 最初のモデルでは、注文オブジェクトにitemURLフィールドがあるという事実を知る必要があります。2番目のモデルでは、アイテムURLを作成する方法を知っている必要があります。どちらの場合も、事前に何かを「知る」必要があるので、HATEOASは実際に何をしてくれますか？

17 web-development  rest 

私はこの記事読んで数年前ですが、あなたのREST APIを確保する巧妙な方法を説明します。基本的に： 各クライアントには一意の公開/秘密キーペアがあります クライアントとサーバーのみが秘密鍵を知っています。有線で送信されることはありません 各リクエストで、クライアントはいくつかの入力（リクエスト全体、現在のタイムスタンプ、およびプライベートキー）を受け取り、それらをHMAC関数で実行してリクエストのハッシュを生成します 次に、クライアントは通常のリクエスト（公開キーを含む）とハッシュをサーバーに送信します サーバは（提供された公開鍵に基づいて）クライアントの秘密鍵を検索し、要求はの被害者ではないことを検証（確かに私は理解していないことを）いくつかのタイムスタンプのチェックを行い、リプレイ攻撃 すべてが順調であれば、サーバーは秘密鍵と同じHMAC関数を使用して、リクエストの独自のハッシュを生成します 次に、サーバーは両方のハッシュ（クライアントが送信したハッシュとクライアントが生成したハッシュ）を比較します。それらが一致する場合、要求は認証され、続行が許可されます それから私はJWTを偶然見つけました。ただし、最初の記事ではJWTについてまったく言及していないため、JWTが上記の認証ソリューションと異なるのかどうか、またそうである場合はその方法について疑問に思っています。

16 security  rest  authentication  keys  hmac 

より速いパフォーマンスとは何ですか？REST APIを作成し、WebアプリでREST APIを使用してデータベースとのすべてのやり取りを行うか、データベースに直接クエリを実行します（つまり、JDBC for Javaなどのデータベースのクエリに使用する一般的なオブジェクトを使用します）？ RESTでの見方： コード内にオブジェクトを作成して、RESTメソッドを呼び出します HTTPメソッドを呼び出す REST API内のコードがデータベースを照会します データベースがデータを返します REST APIコードはデータをJsonにまとめてクライアントに送信します クライアントはJson / XML応答を受け取ります コード内のオブジェクトへの応答をマップする 一方、データベースを直接クエリする場合： データベースをクエリするクエリ文字列でオブジェクトを作成します データベースがデータを返します コード内のオブジェクトへの応答をマップする これは、REST APIの使用が遅くなることを意味しないのでしょうか？たぶんそれはデータベースのタイプ（SQL vs NoSQL）に依存しますか？

16 database  rest  sql 

低速のモバイル接続で時々使用される単一ページのアプリケーションを準備しています。その一部は、APIリクエストの点でかなり重い（新しい画面表示のために10個の異なるリソースをフェッチする）。 さて、これらのサービスを、必要なすべてのデータを提供するサービスにマージするのは良い考えですが、RESTの原則に関しては「純粋」ではありませんか？予想される大幅なパフォーマンスの向上はありますか？

16 api  rest  http 

ユニットテストは初めてで、DBを呼び出してDTOを設定するREST Webメソッドが1つあります。擬似コードは public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 私の疑問は、含まれるこれらのメソッドとテストのタイプ（Integration / Unit）のテストの書き方です。単体テストの場合、DBにアクセスする必要がありますか。そうであり、顧客IDを渡してアサーションをほとんど行わない場合、データが最終的に変更されて失敗する可能性があります。 ここでこれらの概念を理解している何かが欠けていると思います。

16 testing  unit-testing  rest  integration-tests 

ユーザーとリンクの2つのリソースがあります。 ユーザーは複数のリンクを関連付けることができます。次のURIでユーザーに関連付けられたリンクにアクセスできるように、RESTful APIを設計しました。 /users/:id/links ただし、常にリンクだけのURIが必要です。ユーザーに関係なく、すべてのリンクが必要な場合があります。 このために私は： /links これは大丈夫ですか？リンクに2つのURIがありますか？ 代わりに、次のようなURIを使用してユーザーのリンクにアクセスする必要があるかどうか疑問に思います。 /links/user/:id または /links/?user=:id この方法では、リンク用のリソースは1つしかありません。

16 api  rest  api-design 

お客様のドキュメントに対して実行する印刷操作があります。追加、更新、削除など、他の標準操作も実行する必要があります。だから、私は次のものを持っています： 新しい顧客を作成する場合：URI = / customer / {id}、タイプ= POST、Methodname = CreateCustomer（） 更新の場合：URI：/ customer / {id}、タイプ= PUT、メソッド= UpdateCstomer（） 顧客の削除：URI = / customer / {id}、タイプ= DELETE、メソッド名= DeleteCustomer（） ビューの場合：URI：/ customer / {id}、タイプ= GET、メソッド= GetCustomer（） 今、その顧客のためにドキュメントを印刷する必要がある場合、印刷機能が必要です。私のURIは次のようになります：/ customer / {id}、type = POST、method = PrintCustomer（）。しかし、CreateCustomerにはそのURIとPOSTタイプを使用しました。URIを/ customer / Print / {id}、タイプ= POST、メソッド= PrintCustomer（）のようにしたかったのです。 しかし、URIに「印刷」動詞を含めることはできません。これを行う最良の方法は何ですか？URIとして/ customer / document / …

16 rest 

RESTful Webサービスと、主にSilverlightにあるいくつかのクライアントアプリケーションを実装しています。APIのサーバー側とクライアント側の両方を開発するための多数のオプションを見つけていますが、どちらが最善のアプローチかはわかりません。私は、安定性と、数か月後に存在し続けるプラットフォームについて心配しています。 .NET 3.5でRESTスターターキットの使用を開始しましたが、.NET 4.0への更新時に新しいWCF Web APIに移行しました。すべてのドキュメントは、WCF Web APIがRSKの代替品であることを示しています。ただし、Web APIはPreview 4のみにあり、SilverlightまたはWindows Phone 7クライアントのサポートはまだ含まれていません。 WCF Web APIは、System.ServiceModel.Webライブラリで提供されるWCF WebHttp Servicesの上部のラッパーのように見えるため、組み込みのものを使用する方が簡単かもしれませんが、Web APIにはいくつかの素晴らしい機能があります。 クライアント側に最適なコースを決定しようとして、私は特に縛られています。私の主な要件は、クライアント側オブジェクトへのデシリアライズを迅速かつ簡単にサポートする必要があることです。Web APIは優れたクライアントライブラリを提供しますが、Silverlightバージョンはありません。 最新のアプローチと、積極的に開発およびサポートされているツールセットを使用したいと思います。 REST Starter Kitは本当に時代遅れですか？ WCF Web APIツールキットの実装に成功した人はいますか？ にある組み込みのWCF WebHttpサービス機能でこれらのいずれかを使用するメリットはありSystem.ServiceModel.Webますか？ どのクライアント（Web、Silverlightなど）でも機能する単一のソリューションはありますか？ どのような提案がありますか？

16 .net  rest  wcf 

すべての主要なモバイルプラットフォーム（iOS、Android、Windows）のモバイルアプリケーションを対象とする新しいプロジェクトをすぐに開始します。これは、クライアントサーバーアーキテクチャになります。 アプリは情報提供とトランザクションの両方です。トランザクション部分については、トランザクションを行う前にアカウントを持ちログインする必要があります。私はモバイル開発が初めてなので、これらのプラットフォームで認証部分がどのように行われるかはわかりません。クライアントはREST APIを介してサーバーと通信します。もちろんHTTPSを使用します。 ユーザーがアプリを開いたときにログインするか、トランザクションを実行するときにのみログインするかはまだ決めていません。 次の質問がありました。 1）Facebookアプリケーションと同様に、アプリケーションを初めて開くときにのみ資格情報を入力します。その後、アプリを開くたびに自動的にサインインされます。これをどのように達成しますか？単に資格情報を暗号化してデバイスに保存し、アプリを起動するたびに送信するだけです？ 2）REST APIに対して行われた（トランザクション）要求ごとにユーザーを認証する必要がありますか、またはトークンベースのアプローチを使用する必要がありますか？ 他の認証方法をお気軽にご提案ください。 ありがとう！

16 rest  authentication  mobile 

URLのREST APIのバージョンを指定することは非常に一般的です。具体的には、パスの先頭、つまり次のようなものです。 POST /api/v1/accounts GET /api/v1/accounts/details ただし、バージョンが各APIに関連付けられているデザインは見ていません。つまり、各APIのバージョンを個別に管理します。すなわち： POST /api/accounts/v2 GET /api/accounts/details/v3 このアプローチを使用すると、破壊的な変更が必要なときに特定のAPIのAPIバージョンをインクリメントします。API全体のバージョンをインクリメントする必要はありません。 一般的なスタイルの代わりにこのスタイルを使用することの欠点は何ですか？

15 rest  api-design  versioning  enterprise-architecture  engineering