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

REST(Representational State Transfer)は、World Wide Webなどの分散ハイパーメディアシステム用のソフトウェアアーキテクチャのスタイルです。異種システム間で統一されたインターフェースを持つことから生じるサーバーからのクライアントの本質的な分離により、SOAPなどのRPCアーキテクチャーに比べて人気が高まっています。

16
Spring MVC @PathVariableが切り捨てられる
情報へのRESTfulアクセスを提供するコントローラーがあります。 @RequestMapping(method = RequestMethod.GET, value = Routes.BLAH_GET + "/{blahName}") public ModelAndView getBlah(@PathVariable String blahName, HttpServletRequest request, HttpServletResponse response) { 私が経験している問題は、特殊文字を含むパス変数でサーバーにアクセスすると、切り捨てられることです。例: http:// localhost:8080 / blah-server / blah / get / blah2010.08.19-02:25:47 パラメータblahNameはblah2010.08になります ただし、request.getRequestURI()の呼び出しには、渡されたすべての情報が含まれています。 Springが@PathVariableを切り捨てないようにする方法はありますか?
142 java  spring  rest  spring-mvc  get 

5
RestSharp JSONパラメータの投稿
MVC 3 APIに対して非常に基本的なREST呼び出しを行おうとしていますが、渡したパラメーターがアクションメソッドにバインドされていません。 クライアント var request = new RestRequest(Method.POST); request.Resource = "Api/Score"; request.RequestFormat = DataFormat.Json; request.AddBody(request.JsonSerializer.Serialize(new { A = "foo", B = "bar" })); RestResponse response = client.Execute(request); Console.WriteLine(response.Content); サーバ public class ScoreInputModel { public string A { get; set; } public string B { get; set; } } // …

7
RESTful APIでパスパラメータとクエリパラメータを使用するのはいつですか?
RESTful APIを非常に予測可能にしたいと考えています。クエリパラメータを使用するのではなく、URIを使用してデータのセグメンテーションを行うタイミングを決定するためのベストプラクティスは何ですか。 ページネーション、並べ替え、およびグループ化をサポートするシステムパラメータは、「?」の後に来るのが理にかなっています。しかし、 'status'や 'region'などのフィールド、またはコレクションをセグメント化するその他の属性についてはどうでしょうか。それらもクエリパラメータになる場合、パスパラメータをいつ使用するかを知る上での経験則は何ですか?

5
HATEOAS(REST-architecture)の実際の例[終了]
現在のところ、この質問はQ&A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問が改善され、場合によっては再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 誰もが気付いているかもしれませんが、実際には多くの偽/基本的なREST-APIがあります(HTTP-APIを実装し、アプリケーションの状態としてのハイパーテキスト要件に従わずにRESTと呼びます)。最初にRESTパラダイムを指定した男、ロイT.フィールディングの有名な怒りに)。 真のハイパーテキスト駆動型REST実装の実用的な例と、状態遷移に関連するアプリケーション固有のメディアタイプ定義を見つけることができませんでした。 そのような実装の公にアクセス可能な例はありますか?
140 api  rest  hateoas 


12
オブジェクト内のアイテムの総数を返すのに最適なRESTfulメソッドは何ですか?
私が関わっている大規模なソーシャルネットワーキングウェブサイト用のREST APIサービスを開発しています。これまでのところ、うまく機能しています。私が発行することができGET、POST、PUTおよびDELETEオブジェクトのURLへのリクエストや自分のデータに影響を与えます。ただし、このデータはページングされます(一度に30結果に制限されます)。 しかし、私のAPIを介して言う、メンバーの総数を取得するための最良のRESTful方法は何でしょうか? 現在、私は次のようなURL構造にリクエストを発行しています。 / api / members — メンバーのリストを返します(上記のように一度に30) / api / members / 1 —使用されるリクエストメソッドに応じて、単一のメンバーに影響します 私の質問は、同様のURL構造を使用してアプリケーションのメンバーの総数を取得するにはどうすればよいですか?id(FacebookのGraph APIと同様に)フィールドだけを要求して結果をカウントすることは、30の結果のスライスしか返されないため、明らかに効果がありません。
139 rest  restful-url 

2
(DotNetOpenAuthを使用して)サードパーティのOAuthプロバイダーによる認証を許可しながら、OAuthでREST APIを保護する
製品のユーザーがWebユーザーインターフェイスを使用せずに製品の機能と直接統合できるように、単純なREST APIを備えた製品があります。 最近、さまざまなサードパーティから、デスクトップクライアントとAPIを統合して、私の製品のユーザーがそのサードパーティのアプリケーションを使用してデータにアクセスできるようにすることに関心を示しています。 Twitterを使用したいアプリケーションは、Twitterがホストするログインページを使用して認証を行い、そのユーザーのデータにアクセスするための特定のアプリケーション権限を付与します。「許可」または「拒否」ボタンをクリックすると、認証プロセスが完了します。Facebookは私が言うことができる最高のメカニズムを使用しています。 さらなる調査の結果、これは実際のOAuthのようであり、私のAPIは.Netベースであるため、DotNetOpenAuthを使用して同様のメカニズムを提供する必要があると考えています。残念ながら、サンプルはまばらに文書化されており(もしあれば)、オンラインで見つけることができる唯一のチュートリアルは、サードパーティのプロバイダーを使用してユーザーがWebサイトにログインできるように、ユーザーにログインメカニズムを提供するのに役立つことに集中しているようです。 私が本当にやりたいことは、REST APIでWebアプリケーションのすべてのコア認証とビジネスロジックを処理し、内部的には、OAuthを介してAPIを使用するだけのアプリケーションです。ユーザーは、ユーザー名とパスワードを直接使用するか、MyOpenIDやFacebookなどのサードパーティプロバイダーを介してWebサイトで認証し、Webサイトは返されたトークンを使用してREST APIに対して認証を行います。 基本的に、OAuthサービスをホストするためにAPIが必要であるように見えますが、ユーザーにサードパーティのOAuthサービスを使用させる必要もあります。どうしようもないのですが、OAuthを十分に理解していないので、複雑すぎたり、やろうとしていることが良い方法か悪い方法かを判断できません。 誰かが、少なくとも私が実行する必要のある手順の概要、またはこれを実現するために何を見る必要があるかを教えてもらえますか?または、いくつかのチュートリアルを教えてください。または私の提案を爆破し、私はこれについて(アーキテクチャ的に)すべて間違っていると言っていますか?

11
Spring MVC-Rest Controllerで単純な文字列をJSONとして返す方法
私の質問は基本的にこの質問のフォローアップです。 @RestController public class TestController { @RequestMapping("/getString") public String getString() { return "Hello World"; } } 上記では、Springは「Hello World」を応答本文に追加します。文字列をJSON応答として返すにはどうすればよいですか?引用符を追加できることは理解していますが、それはハックのように感じられます。 この概念の説明に役立つ例を提供してください。 注:これをHTTP応答本文に直接書きたくはありません。文字列をJSON形式で返したいです(有効なJSON形式の応答を必要とするRestyGWTでコントローラーを使用しています)。
137 java  json  spring  rest  spring-mvc 

11
ASP.Net Web API GETに複数のパラメーターを渡すにはどうすればよいですか?
.Net MVC4 Web APIを使用して(うまくいけば)RESTful APIを実装しています。システムにいくつかのパラメーターを渡し、システムに何らかのアクションを実行させてから、オブジェクトのリストを結果として返す必要があります。具体的には、2つの日付を渡し、その間にあるレコードを返しています。また、後続の呼び出しがシステムで再処理されないように、返されたレコードを追跡しています。 私はいくつかのアプローチを検討しました: paramsを1つのJSON文字列にシリアル化し、APIで分離します。 http://forums.asp.net/t/1807316.aspx/1 クエリ文字列でパラメータを渡します。 複数のクエリパラメータをRESTful APIに渡す最良の方法は何ですか? ルートのパラメータの定義:api / controller / date1 / date2 本質的にparamsでオブジェクトを渡すことができるPOSTを使用します。 Web APIが(現在)サポートしているため、ODATAを調査しています。私はまだこれで多くのことをしていないので、私はそれにあまり詳しくありません。 適切なRESTプラクティスは、データがプルされるときはGETを使用する必要があることを示しているようです。ただし、GETもnullipotent(副作用を生成しない)である必要があります。APIシステムでレコードをマークしているため、特定の実装がこれに違反しているかどうかを知り、副作用を生成しています。 また、可変パラメーターのサポートについても質問しました。入力パラメーターリストが変更された場合、それが頻繁に発生する場合、選択肢3のルートを再定義するのは面倒です。そして、パラメータが実行時に定義されるとどうなるか... いずれにせよ、私の特定の実装では、どの選択(もしあれば)が最良と思われますか?

4
REST、HTTP DELETEおよびパラメーター
HTTP DELETEリクエストにパラメーターを提供することに関してRESTfulでないものはありますか? 私のシナリオでは、「本当に削除してもよろしいですか?」をモデル化しています。シナリオ。場合によっては、リソースの状態は、要求された削除が無効である可能性があることを示唆しています。おそらく、自分で削除の確認が必要ないくつかのシナリオを想像できます。 私たちが採用したソリューションは、削除リクエストにパラメーターを渡して、削除を続行してもよいことを示すことです( "?force_delete = true") 例えば DELETE http://server/resource/id?force_delete=true 私はそれがまだ落ち着いていると信じています: (a)DELETEのセマンティクスは変更されていません。ユーザーは通常のDELETEリクエストを送信できますが、409で失敗する可能性があり、応答の本文に理由が説明されています。(説明する価値がない理由で)場合によってはユーザーにプロンプ​​トを表示する理由がないため、失敗する可能性があると言います。 (b)Royの論文には、RESTの精神に反することを示唆するものは何もありません。なぜHTTPはRESTの1つの実装にすぎないので、なぜHTTPパラメータを渡すことが重要なのでしょうか。 これがRESTfulでない理由を否定する決定的な声明を誰かが私に指摘できますか? 関連する質問で、ユーザーがforce_deleteを指定しなかった場合、返されます409 Conflict-これが最も適切な応答コードですか? ファローアップ さらに調査した結果、DELETEにパラメーターを追加すると、いくつかの原則に違反する可能性があると思います。 1つ目は、実装が「Uniform Interface」に違反している可能性があることです(Royの論文のセクション5.1.5を参照)。 'force_delete'を追加することで、すでに適切に定義されたDELETEメソッドに制約を追加します。この制約は私たちだけに意味があります。 また、確認ダイアログは本当にUIの問題であり、すべてのクライアントが削除の確認を望んでいるわけではないため、「5.1.2クライアントサーバー」に違反していると主張することもできます。 誰か提案?
135 http  rest 

12
レストコレクションでのページング
JSONドキュメントのコレクションに直接RESTインターフェースを公開することに興味があります(CouchDBまたはPersevereを考えてください)。私が直面している問題はGET、コレクションが大きい場合にコレクションルートでの操作を処理する方法です。 例として、Questions各行がドキュメントとして公開されているStackOverflowのテーブルを公開しています(必ずしもそのようなテーブルがあるわけではなく、「ドキュメント」のかなり大きなコレクションの具体例にすぎません)。コレクションはで利用可能になるでしょう/db/questions通常のCRUDのAPIを使用してGET /db/questions/XXX、PUT /db/questions/XXX、POST /db/questions遊びです。コレクション全体を取得する標準的な方法は次のGET /db/questionsとおりですが、それが各行をJSONオブジェクトとして単純にダンプする場合、かなり大きなダウンロードとサーバー側での多くの作業が発生します。 もちろん、解決策はページングです。道場は、この問題を解決したJsonRestStore使用の巧妙なRFC2616に準拠した拡張を介してRangeカスタム範囲部とヘッダitems。結果は206 Partial Content、要求された範囲のみを返すです。クエリパラメータに対するこのアプローチの利点は、クエリ文字列(クエリなど)を残すことです(たとえばGET /db/questions/?score>200、エンコードされます%3E)。 このアプローチは、私が望む行動を完全にカバーしています。問題は、RFC 2616が206の応答について次のように指定していることです(強調は私のものです)。 要求が Rangeヘッダフィールド(含んでいなければなりませんセクション14.35を所望の範囲を示す)、及び場合-Rangeヘッダフィールド(含まれている可能性があり部14.27を要求する条件を作るために)。 これは、ヘッダーの標準的な使用法のコンテキストでは理にかなっていますが、私が206応答を、単純なクライアント/ランダムなユーザーの探索を処理するデフォルトにしたいので問題です。 私は解決策を探すために詳細にRFCを調査しましたが、私の解決策に不満があり、SOの問題への取り組みに興味があります。 私が持っていたアイデア: 戻り値200とContent-Rangeヘッダ!-私はこれが間違っているとは思いませんが、応答が部分的なコンテンツのみであることを示すより明白な指標が望ましいです。 戻り値400 Range Required -必須ヘッダーに特別な400応答コードはないため、デフォルトのエラーを使用して手動で読み取る必要があります。これにより、Webブラウザー(またはRestyのような他のクライアント)での探索もより困難になります。 クエリパラメータを使用する -標準的なアプローチですが、永続的なクエリを許可すると、クエリの名前空間に割り込むことができます。 戻るだけ206!-ほとんどのクライアントはおかしくならないだろうと思うが、RFCのMUSTには反対したくない スペックを拡張!Return266 Partial Content -206とまったく同じように動作しますが、含まれてはならないリクエストに応答しますRangeヘッダーをます。私は266が衝突の問題に遭遇してはならないほど十分に高いことを理解しています。それは私には理にかなっていますが、これがタブーと見なされるかどうかははっきりしません。 これはかなり一般的な問題だと思います。私や他の誰かがホイールを再発明しないように、これをある種の事実上の方法で実行してもらいたいと思います。 コレクションが大きい場合にHTTP経由で完全なコレクションを公開する最良の方法は何ですか?

6
PHP cURLでJSONデータをPOSTする方法
これが私のコードです、 $url = 'url_to_post'; $data = array( "first_name" => "First name", "last_name" => "last name", "email"=>"email@gmail.com", "addresses" => array ( "address1" => "some address", "city" => "city", "country" => "CA", "first_name" => "Mother", "last_name" => "Lastnameson", "phone" => "555-1212", "province" => "ON", "zip" => "123 ABC" ) ); $data_string = …
132 php  json  rest  curl 



14
JSONのRestTemplateを介したPOSTリクエスト
私は問題を解決する方法の例を見つけられなかったので、あなたに助けを求めたいと思います。JSONでRestTemplateオブジェクトを使用してPOSTリクエストを送信することはできません 私が得るたびに: org.springframework.web.client.HttpClientErrorException:415 Unsupported Media Type RestTemplateを次のように使用します。 ... restTemplate = new RestTemplate(); List<HttpMessageConverter<?>> list = new ArrayList<HttpMessageConverter<?>>(); list.add(new MappingJacksonHttpMessageConverter()); restTemplate.setMessageConverters(list); ... Payment payment= new Payment("Aa4bhs"); Payment res = restTemplate.postForObject("http://localhost:8080/aurest/rest/payment", payment, Payment.class); 私のせいは何ですか?
126 java  json  spring  rest  resttemplate 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.