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

HTTP / 1.1仕様によると： このPOSTメソッドは、元のサーバーが、リクエストで囲まれたエンティティRequest-URIを、Request-Line つまり、POSTを作成するために使用されます。 このPUTメソッドは、囲まれたエンティティを指定されたの下に保存することを要求しますRequest-URI。がRequest-URI既存のリソースを参照する場合、囲まれたエンティティは、オリジンサーバーに存在するエンティティの変更バージョンと見なされるべきです（SHOULD）。がRequest-URI既存のリソースを指しておらず、そのURIが要求側のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます。」 つまり、PUTを作成または置換するために使用されます。 では、どれを使用してリソースを作成する必要がありますか？または、両方をサポートする必要がありますか？

5373 http  rest  post  put 

RESTfulプログラミングとは正確には何ですか？

3983 http  rest  definition 

Ubuntuを使用してcURLをインストールしました。Spring RESTアプリケーションをcURLでテストしたい。私はPOSTコードをJava側で記述しました。ただし、cURLでテストしたいと思います。JSONデータを投稿しようとしています。データの例は次のとおりです。 {"value":"30","type":"Tip 3","targetModule":"Target 3","configurationGroup":null,"name":"Configuration Deneme 3","description":null,"identity":"Configuration Deneme 3","version":0,"systemId":3,"active":true} 私はこのコマンドを使用します： curl -i \ -H "Accept: application/json" \ -H "X-HTTP-Method-Override: PUT" \ -X POST -d "value":"30","type":"Tip 3","targetModule":"Target 3","configurationGroup":null,"name":"Configuration Deneme 3","description":null,"identity":"Configuration Deneme 3","version":0,"systemId":3,"active":true \ http://localhost:8080/xx/xxx/xxxx それはこのエラーを返します： HTTP/1.1 415 Unsupported Media Type Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1051 Date: Wed, 24 Aug 2011 …

2833 json  rest  spring-mvc  curl  http-headers 

アプリケーション用の新しいRESTful Webサービスを開発しています。 特定のエンティティに対してGETを実行すると、クライアントはエンティティのコンテンツを要求できます。一部のパラメーターを追加する場合（リストの並べ替えなど）、これらのパラメーターをクエリ文字列に追加できます。 あるいは、リクエストの本文でこれらのパラメーターを指定できるようにしたいです。 HTTP / 1.1はこれを明示的に禁止していないようです。これにより、より多くの情報を指定できるようになり、複雑なXML要求を指定しやすくなる場合があります。 私の質問： これは完全に良いアイデアですか？ HTTPクライアントは、GETリクエスト内のリクエスト本文の使用に問題がありますか？ http://tools.ietf.org/html/rfc2616

2110 rest  http  http-get 

Webサービス通信プロトコルとしてのSOAPとRESTの違いについての記事を読みましたが、SOAPに対するRESTの最大の利点は次のとおりだと思います。 RESTはより動的であり、UDDI（Universal Description、Discovery、およびIntegration）を作成および更新する必要はありません。 RESTはXML形式のみに制限されていません。RESTful Webサービスはプレーンテキスト/ JSON / XMLを送信できます。 しかし、SOAPはより標準化されています（例：セキュリティ）。 それで、私はこれらの点で正しいですか？

1241 rest  web-services  http  soap  definition 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 WebサービスREST APIバージョン管理の既知のハウツーまたはベストプラクティスはありますか？ AWSがエンドポイントのURLによってバージョン管理を行うことに気づきました。これが唯一の方法ですか、それとも同じ目標を達成する他の方法はありますか？複数の方法がある場合、それぞれの方法のメリットは何ですか？

877 rest  versioning 

クライアントがオブジェクトを保存できるサーバーを構築しています。これらのオブジェクトはクライアント側で完全に構築され、オブジェクトの存続期間全体にわたって永続的なオブジェクトIDを備えています。 クライアントがPUTを使用してオブジェクトを作成または変更できるように、APIを定義しました。 PUT /objects/{id} HTTP/1.1 ... {json representation of the object} {id}はオブジェクトIDであるため、Request-URIの一部です。 ここで、クライアントがPOSTを使用してオブジェクトを作成できるようにすることも検討しています。 POST /objects/ HTTP/1.1 ... {json representation of the object, including ID} POSTは「追加」操作を意図しているので、オブジェクトがすでにそこにある場合にどうすればよいかわかりません。リクエストを変更リクエストとして処理する必要がありますか、それともエラーコード（どちらか）を返す必要がありますか？

842 rest  http  http-status-codes 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 REST APIまたはサービスを設計するときに、セキュリティ（認証、承認、ID管理）を処理するための確立されたベストプラクティスはありますか？ SOAP APIを構築する場合、ガイドとしてWS-Securityがあり、このトピックに関する多くの文献が存在します。RESTエンドポイントの保護に関する情報が少なくなりました。 RESTにはWS- *に類似した仕様が意図的にないことを理解していますが、ベストプラクティスまたは推奨パターンが浮かび上がってきたことを願っています。 議論や関連文書へのリンクは非常に高く評価されます。必要に応じて、.NET Frameworkのv3.5を使用して構築されたREST API /サービスのPOX / JSONシリアル化メッセージでWCFを使用します。

828 wcf  security  rest  authorization  rest-security 

RESTベースのAPIを使用してアプリケーションを構築していて、各リクエストのステータスコードを指定するようになりました。 検証に失敗したリクエスト、またはリクエストがデータベースに重複を追加しようとしている場合、どのステータスコードを送信する必要がありますか？ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを確認しましたが、どれも正しくないようです。 ステータスコードを送信する際の一般的な方法はありますか？

826 http  rest  http-status-codes 

これはおそらく愚かな質問になるでしょうが、私はそれらの夜の1つを持っています。アプリケーションでは、RESTful APIを開発しており、クライアントがデータをJSONとして送信することを望んでいます。このアプリケーションの一部では、クライアントはファイル（通常は画像）と画像に関する情報をアップロードする必要があります。 これが単一のリクエストでどのように発生するかを追跡するのに苦労しています。ファイルデータをJSON文字列にBase64することは可能ですか？サーバーへの2つの投稿を実行する必要がありますか？これにはJSONを使用しないでください。 ちなみに、私たちはバックエンドでGrailsを使用しています。これらのサービスは、ネイティブモバイルクライアント（iPhone、Androidなど）によってアクセスされます。

757 json  rest  grails  file-upload 

RESTful認証とは何を意味し、どのように機能しますか？Googleで適切な概要を見つけることができません。私の唯一の理解は、URLでセッションキー（メモ）を渡すことですが、これはひどく間違っている可能性があります。

745 rest  authentication  restful-authentication  rest-security 

呼び出しているAPIの要求に応じて、オブジェクトのContent-Typeヘッダーを設定しようとしHttpClientています。 Content-Type以下のように設定してみました： using (var httpClient = new HttpClient()) { httpClient.BaseAddress = new Uri("http://example.com/"); httpClient.DefaultRequestHeaders.Add("Accept", "application/json"); httpClient.DefaultRequestHeaders.Add("Content-Type", "application/json"); // ... } Acceptヘッダーを追加できますが、追加しようとするContent-Typeと次の例外がスローされます。 誤ったヘッダー名。リクエストヘッダーはでHttpRequestMessage、レスポンスヘッダーはHttpResponseMessageで、コンテンツヘッダーはHttpContentオブジェクトで使用してください 。 リクエストにContent-Typeヘッダーを設定するにはどうすればよいHttpClientですか？

739 c#  asp.net  api  http  rest 

誰かがRESTとSOAPを分かりやすい英語で説明できますか？そして、Webサービスはどのように機能しますか？

722 rest  soap 

HTTP DELETE要求を発行する場合、要求URIは削除するリソースを完全に識別する必要があります。ただし、リクエストのエンティティボディの一部として追加のメタデータを追加することはできますか？

717 http  rest 

まず、いくつかの定義： PUTはセクション9.6 RFC 2616で定義されています。 PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、元のサーバーにあるエンティティの変更バージョンと見なされるべきです（SHOULD）。Request-URIが既存のリソースを指さず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます。 PATCHはRFC 5789で定義されています。 PATCHメソッドは、要求エンティティに記述されている一連の変更を、Request-URIで識別されるリソースに適用するように要求します。 また、RFC 2616セクション9.1.2によれば、PUTはべき等ではなく、PUTはべき等です。 次に、実際の例を見てみましょう。/usersデータを使用してPOSTを実行し、{username: 'skwee357', email: 'skwee357@domain.com'}サーバーがリソースを作成できる場合、サーバーは201とリソースの場所で応答し（仮定/users/1）、次のGET呼び出し/users/1はを返し{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}ます。 次に、メールを変更したいとします。メールの変更は「一連の変更」と見なされるため/users/1、「パッチドキュメント」でパッチを適用する必要があります。私のケースでは、JSON形式のドキュメントのようになります。{email: 'skwee357@newdomain.com'}。その後、サーバーは200を返します（許可に問題がない場合）。これは私に最初の質問をもたらします： パッチはべき等ではありません。RFC 2616とRFC 5789でそう述べられています。ただし、同じPATCHリクエストを（新しいメールで）発行すると、同じリソースの状態が取得されます（メールはリクエストされた値に変更されます）。なぜPATCHはべき等ではないのですか？ PATCHは比較的新しい動詞（2010年3月に導入されたRFC）であり、一連のフィールドの「パッチ」または変更の問題を解決するようになります。PATCHが導入される前は、誰もがPUTを使用してリソースを更新していました。しかし、PATCHが導入された後は、PUTが何に使用されるのか混乱します。そして、これは私に私の2番目の（そして主要な）質問をもたらします： PUTとPATCHの本当の違いは何ですか？特定のリソースの下のエンティティ全体を置き換えるために PUTが使用される可能性があることをどこかで読んだので、（PATCHのような属性のセットの代わりに）エンティティ全体を送信する必要があります。そのような場合の実際の使用法は何ですか？特定のリソースURIにあるエンティティをいつ置換または上書きしますか。また、そのような操作がエンティティの更新/パッチ適用と見なされないのはなぜですか？PUTで私が目にする唯一の実用的な使用例は、コレクションに対してPUTを発行すること、つまり/usersコレクション全体を置き換えることです。PATCHが導入された後、特定のエンティティでPUTを発行しても意味がありません。私が間違っている？

680 json  rest  http  put  http-method