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

WebサービスのテストにPostman Chrome拡張機能を使用しています。 データ入力には3つのオプションがあります。 rawJSONを送信するためのものだと思います。 他にどのような2つの違いはある、form-dataとx-www-form-urlencoded？

222 forms  web-services  rest  postman 

EC2インスタンスでElasticsearchの実装を使用して公開したRESTful APIを使用して、コンテンツのコーパスにインデックスを付けました。端末（MacOSX）から次のコマンドを実行して、検索のクエリを実行できます。 curl -XGET 'http://ES_search_demo.com/document/record/_search?pretty=true' -d '{ "query": { "bool": { "must": [ { "text": { "record.document": "SOME_JOURNAL" } }, { "text": { "record.articleTitle": "farmers" } } ], "must_not": [], "should": [] } }, "from": 0, "size": 50, "sort": [], "facets": {} }' 上記を使用して、python/requestsまたはを使用してAPIリクエストに変換するにはどうすればよいですかpython/urllib2（どちらを使用するかわからない-urllib2を使用しているが、リクエストの方が優れていると聞いている...）？ヘッダーなどとして渡しますか？

221 python  api  rest  elasticsearch 

REST APIを構築していますが、問題が発生しました。 REST APIの設計で受け入れられている慣行は、要求されたリソースが存在しない場合は404が返されることです。 しかし、私には、これは不必要なあいまいさを追加します。HTTP 404は、より伝統的に不良URIに関連付けられています。つまり、実際には「正しい場所に到達したが、その特定のレコードが存在しないか、インターネット上にそのような場所がない！どちらがどこなのかわからない...」 次のURIを考えます。 http://mywebsite/api/user/13 404が返ってきたのは、ユーザー13が存在しないためですか？それとも私のURLがそうであったはずだからです： http://mywebsite/restapi/user/13 以前はHTTP 200 OK、レコードが存在しない場合、レスポンスコードとともにNULL結果を返しました。それは単純であり、私の意見では、それが必ずしも受け入れられている実践でなくても、非常にクリーンです。しかし、これを行うより良い方法はありますか？

219 web-services  http  rest 

私たちのWebアプリは.Net Framework 4.0で実行されています。UIはajax呼び出しを通じてコン​​トローラーメソッドを呼び出します。 ベンダーのRESTサービスを利用する必要があります。.Net 4.0でRESTサービスを呼び出す最良の方法を評価しています。RESTサービスは基本認証スキームを必要とし、XMLとJSONの両方でデータを返すことができます。巨大なデータをアップロード/ダウンロードする必要はなく、今後何も表示されません。RESTを使用するためのいくつかのオープンソースコードプロジェクトを調べたところ、プロジェクトに追加の依存関係を正当化するための価値が見つかりませんでした。評価WebClientを開始しましたHttpClient。NuGetから.Net 4.0用のHttpClientをダウンロードしました。 私は間の違いを検索WebClientし、HttpClientそしてこのサイトは、単一のHttpClientは同時コールを処理することができますし、それが解決DNS、クッキーの設定や認証を再利用できることを述べました。違いによって得られる実用的な値はまだわかりません。 WebClient（同期呼び出し）、HttpClient（同期および非同期）のパフォーマンスを確認するために、簡単なパフォーマンステストを行いました。そしてここに結果があります： HttpClientすべてのリクエストに同じインスタンスを使用する（最小-最大） WebClient同期：8 ms-167 ms HttpClient同期：3 ms-7228 ms HttpClient async：985-10405 ms HttpClientリクエストごとに新しいものを使用する（最小-最大） WebClient同期：4 ms-297 ms HttpClient同期：3 ms-7953 ms HttpClient async：1027-10834 ms コード public class AHNData { public int i; public string str; } public class Program { public static HttpClient httpClient = new …

218 c#  .net  rest  webclient  dotnet-httpclient 

したがって、ここでは何も新しいことはありません。説明を求めているだけで、他の投稿では何も見つけられないようです。 私は思い切って新しいリソースを作成しています： /books (POST) ボディ付き： { title: 'The Lion, the Witch and the Wardrobe', author: 'C. S. Lewis' } 新しいリソースのLocationヘッダーを含む201（Created）を返す必要があることはわかっています。 Location: /books/12345 自分では答えられないように思える質問は、サーバーが本文で返す必要があるものです。 私はよくこのタイプの応答をしました： { id: 12345, title: 'The Lion, the Witch and the Wardrobe', author: 'C. S. Lewis' } これを行った理由はいくつかあります。 私はangularjsのようなフロントエンドフレームワーク用のAPIを書きました。私の特定のケースでは、角度リソースを使用しており、リソースを見つけるためにリソースのIDだけが必要になることがよくあります。応答本文でIDを返さなかった場合は、Locationヘッダーから解析する必要があります。 すべての本のGETでは、通常、IDだけでなくオブジェクト全体を返します。この意味で、クライアントコードは、IDをどこから取得するか（場所のヘッダーまたは本文）を区別する必要はありません。 今、私は本当に灰色の領域にいることを知っていますが、ほとんどの人は、リソース全体を返すことは「悪い」習慣だと言っています。しかし、サーバーがリソースに情報を変更または追加した場合はどうなるでしょうか。それは間違いなくIDを追加しますが、タイムスタンプのような他のものも追加するかもしれません。リソース全体を返さない場合は、POSTを実行し、IDを返してから、クライアントにGETを実行して新しいリソースを取得させる方が良いでしょう。

217 rest  angularjs  angularjs-resource 

Jerseyを使用してJAX-RS（別名、JSR-311）を学習しています。ルートリソースを正常に作成し、パラメーターをいじっています。 @Path("/hello") public class HelloWorldResource { @GET @Produces("text/html") public String get( @QueryParam("name") String name, @QueryParam("birthDate") Date birthDate) { // Return a greeting with the name and age } } これはうまく機能し、Date（String）コンストラクターによって理解される現在のロケールのすべての形式を処理します（YYYY / mm / ddおよびmm / dd / YYYYなど）。しかし、無効な値または理解できない値を指定すると、404応答が返されます。 例えば： GET /hello?name=Mark&birthDate=X 404 Not Found この動作をカスタマイズするにはどうすればよいですか？おそらく異なる応答コード（おそらく「400 Bad Request」）でしょうか？エラーの記録についてはどうですか？トラブルシューティングに役立つように、カスタムヘッダーに問題の説明（「不正な日付形式」）を追加することはできますか？または、5xxステータスコードとともに詳細を含むエラー応答全体を返しますか？

216 java  rest  error-handling  jersey  jax-rs 

RESTfulスタイルのプログラミングでは、ビルディングブロックとしてHTTPメソッドを使用する必要があります。どのメソッドが従来のCRUDメソッドと一致するかについては、少し混乱しています。GET / ReadとDELETE / Deleteは明白です。 ただし、PUT / POSTの違いは何ですか？それらは、作成と更新と1対1で一致しますか？

213 http  rest  crud  http-method 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する REST APIを作成する場合、API内の命名規則に関するガイドラインやデファクトスタンダード（例：URLエンドポイントパスコンポーネント、クエリ文字列パラメーター）はありますか？キャメルキャップは標準またはアンダースコアですか？他？ 例えば： api.service.com/helloWorld/userId/x または api.service.com/hello_world/user_id/x 注：これはRESTful API設計の問題ではなく、使用される最終的なパスコンポーネントやクエリ文字列パラメーターに使用する命名規則のガイドラインです。 任意のガイドラインをいただければ幸いです。

212 api  rest  naming-conventions 

私は顧客管理システム用のRESTfulサービスを作成しており、レコードを部分的に更新するためのベストプラクティスを見つけようとしています。たとえば、呼び出し元がGETリクエストでレコード全体を読み取れるようにしたいとします。ただし、更新の場合、ステータスをENABLEDからDISABLEDに変更するなど、レコードに対する特定の操作のみが許可されます。（これよりも複雑なシナリオがあります） セキュリティ上の理由から、更新されたフィールドのみを含むレコード全体を発信者に送信してほしくありません（また、やり過ぎのように感じます）。 URIを構築するための推奨される方法はありますか？RESTブックを読むとき、RPCスタイルの呼び出しは不快に思われます。 次の呼び出しがID 123の顧客の完全な顧客レコードを返す場合 GET /customer/123 <customer> {lots of attributes} <status>ENABLED</status> {even more attributes} </customer> ステータスを更新するにはどうすればよいですか？ POST /customer/123/status <status>DISABLED</status> POST /customer/123/changeStatus DISABLED ... 更新：質問を補足します。「ビジネスロジックコール」をREST APIに組み込むにはどうすればよいですか？これを行うための合意された方法はありますか？すべてのメソッドが本質的にCRUDであるとは限りません。いくつかは'のような、より複雑なsendEmailToCustomer（123） '、 ' mergeCustomers（123、456） '、 ' countCustomers（） ' POST /customer/123?cmd=sendEmail POST /cmd/sendEmail?customerId=123 GET /customer/count

208 rest 

node.js、express、mongodbを使用してREST APIの計画を開始します。APIは、ウェブサイト（パブリックエリアとプライベートエリア）のデータを提供し、後でモバイルアプリを提供することもあります。フロントエンドはAngularJSで開発されます。 数日間、REST APIのセキュリティ保護について多くのことを読みましたが、最終的な解決策にたどり着けません。私が理解している限りでは、HTTPSを使用して基本的なセキュリティを提供することです。しかし、そのユースケースでAPIをどのように保護できるか： ウェブサイト/アプリの訪問者/ユーザーのみが、ウェブサイト/アプリのパブリックエリアのデータを取得できます 認証および承認されたユーザーのみがプライベートエリアのデータを取得できます（ユーザーが権限を付与したデータのみ） 現時点では、アクティブなセッションを持つユーザーのみがAPIを使用できるようにすることを考えています。ユーザーを認証するには、パスポートを使用し、許可を得るために自分で何かを実装する必要があります。すべてHTTPSの上に。 誰かがベストプラクティスや経験を提供できますか？「アーキテクチャ」に不足はありますか？

204 node.js  rest  express  passport.js 

私はURIにPOSTして、パラメータを送信しようとしています username=me Invoke-WebRequest -Uri http://example.com/foobar -Method POST メソッドPOSTを使用してパラメーターを渡すにはどうすればよいですか？

197 powershell  rest 

いくつかのWebサービスを調べていると、MicrosoftがODataと呼んでいるこの「新しい」テクノロジーに出くわしました。ODataとは何かに関するFAQ内の説明を読んで、ODataとRESTフルWebサービスを区別するのに苦労しています。誰かが違いを理解するのを手伝ってくれませんか？

196 web-services  rest  odata 

RESTfulコントローラーで新しいメソッドを定義する必要があるのはなぜですか？それに続いてcreateメソッドを使用しますか？ グーグル検索は私が探していた答えを私に提供しませんでした。私は違いを理解していますが、なぜ彼らがどのように使用されているのかを知る必要があります。

195 ruby-on-rails  rest 

ユーザー、ウォレットRESTマイクロサービス、および物事を接着するAPIゲートウェイがあるとします。BobがWebサイトに登録するとき、APIゲートウェイは、Userマイクロサービスを介してユーザーを作成し、Walletマイクロサービスを介してWalletを作成する必要があります。 次に、問題が発生する可能性があるいくつかのシナリオを示します。 ユーザーBobの作成は失敗します。問題ありません。エラーメッセージをBobに返します。SQLトランザクションを使用しているため、システム内でBobを見た人はいません。すべて良し ：） ユーザーBobが作成されましたが、ウォレットを作成する前に、APIゲートウェイがハードクラッシュします。これで、ウォレットのないユーザー（データに一貫性がない）ができました。 ユーザーBobが作成され、ウォレットを作成すると、HTTP接続がドロップします。ウォレットの作成が成功したか、成功しなかった可能性があります。 この種のデータの不整合が発生しないようにするには、どのような解決策がありますか？トランザクションが複数のRESTリクエストにまたがることを可能にするパターンはありますか？私はこの問題に触れていると思われる2フェーズコミットのWikipediaページを読みましたが、実際にそれを適用する方法がわかりません。このAtomic Distributed Transactions：RESTfulなデザインペーパーも興味深いですが、まだ読んでいません。 あるいは、RESTがこのユースケースに適していない可能性があることも知っています。この状況を処理してRESTを完全に削除し、メッセージキューシステムのような別の通信プロトコルを使用する正しい方法でしょうか？または、アプリケーションコードに整合性を適用する必要がありますか（たとえば、不整合を検出して修正するバックグラウンドジョブを実行するか、ユーザーモデルに「作成」、「作成」の値などの「状態」属性を設定するなど）。

195 rest  architecture  transactions  microservices 

JSONを受け入れて応答するREST APIを備えたサーバーを開発しています。問題は、クライアントからサーバーに画像をアップロードする必要がある場合です。 注：また、エンティティ（ユーザー）が複数のファイル（carPhoto、licensePhoto）を持ち、他のプロパティ（name、email ...）を持つことができるユースケースについても話しますが、新しいユーザーを作成すると、これらの画像は送信されません。登録プロセスの後に追加されます。 私が知っている解決策ですが、それぞれにいくつかの欠陥があります 1. JSONの代わりにmultipart / form-dataを使用する good：POSTおよびPUTリクエストは可能な限りRESTfulであり、ファイルとともにテキスト入力を含めることができます。 短所：JSONではなく、テストやデバッグなどがmultipart / form-dataに比べてはるかに簡単になりました。 2.個別のファイルの更新を許可する 新しいユーザーを作成するためのPOSTリクエストは画像を追加することを許可していません（これは、私が最初に言ったユースケースでは問題ありません）。 good：すべて（ファイルのアップロード自体を除く）はJSONのままなので、テストとデバッグが簡単です（長さを気にせずに完全なJSONリクエストをログに記録できます） 短所：直感的ではありません。エンティティのすべての変数を一度にPOSTまたはPUTすることはできません。また、このアドレス/users/4/carPhotoはコレクションと見なすことができます（REST APIの標準的な使用例は次のようになります/users/4/shipments）。通常、エンティティの各変数、たとえばusers / 4 / nameをGET / PUTすることはできません（したくありません）。users / 4でGETを使用して名前を取得し、PUTを使用して名前を変更できます。IDの後に何かがある場合、それは通常、users / 4 / reviewsのような別のコレクションです。 3. Base64を使用する JSONとして送信しますが、Base64でファイルをエンコードします。 good：最初のソリューションと同じで、できるだけRESTfulなサービスです。 短所：繰り返しになりますが、テストとデバッグははるかに悪く（ボディにはメガバイトのデータが含まれる可能性があります）、サイズが増加し、クライアントとサーバーの両方で処理時間が長くなります。 私は本当にソリューション番号を使用したいと思います。2、しかし、それはその短所を持っています...誰でも私に「何が最善」の解決策のより良い洞察を与えることができますか？ 私の目標は、できるだけ多くの標準を組み込んだRESTfulサービスを提供することですが、できるだけシンプルにしたいと考えています。

194 json  rest  file-upload  restful-architecture