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

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

13
REST Webアプリケーションでのページネーション
これは、この質問をより一般的に再構成したものです(Rails固有の部分が削除されています)。 RESTful Webアプリケーションのリソースにページネーションを実装する方法がわかりません。私がと呼ばれるリソースを持っているとproductsすると、次のうちどれが最善のアプローチだと思いますか、そしてその理由は次のとおりです。 1.クエリ文字列のみを使用する 例えば。http://application/products?page=2&sort_by=date&sort_how=asc ここでの問題は、全ページキャッシュを使用できないことと、URLがあまりクリーンで覚えにくいことです。 2.リソースとしてのページとソート用のクエリ文字列の使用 例えば。http://application/products/page/2?sort_by=date&sort_how=asc この場合、参照される問題は、それがあるhttp://application/products/pages/1使用して以来、独自のリソースではありませんsort_by=price全く異なる結果をもたらすことができると私はまだページのキャッシュを使用することはできません。 3.リソースとしてのページとソート用のURLセグメントの使用 例えば。http://application/products/by-date/page/2 私は個人的にこの方法を使用しても問題ないと思いますが、これは良い方法ではないと警告されました(理由は示さなかったため、推奨されない理由がわかっている場合はお知らせください) 任意の提案、意見、批判は歓迎以上です。ありがとう。
329 rest  sorting  pagination 

16
Python REST(Webサービス)フレームワークの推奨事項?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 独自のRESTful APIを作成するためにサーバーサイドで使用するためのさまざまなPythonベースのRESTフレームワークの推奨事項のリストはどこにありますか?できれば賛否両論。 ここに推奨事項を追加してください。:)

12
PHPでREST APIを呼び出す
私たちのクライアントは、PHP呼び出しを行う必要があるREST APIを私にくれました。しかし、実際のところ、APIで提供されるドキュメントは非常に限られているため、サービスの呼び出し方法がわかりません。 私はそれをグーグルにしようとしました、しかし現れた唯一のものはすでに期限切れのYahoo!でした。サービスの呼び出し方法に関するチュートリアル。ヘッダーや詳細情報については触れません。 REST APIの呼び出し方法に関する適切な情報、またはREST APIに関するドキュメントはありますか?W3schoolsでも、SOAPメソッドについてのみ説明しているためです。PHPでREST APIを作成するためのさまざまなオプションは何ですか?
317 php  web-services  api  rest 

12
HTTPとRESTの違いは何ですか?
RESTとSOAPの違いについてたくさん読んだ後、RESTはHTTPの単なる別の言葉であるという印象を受けました。RESTがHTTPに追加する機能について誰かが説明できますか? 注:RESTとSOAPの比較を探しているのではありません。 更新:ご回答ありがとうございます。RESTは、HTTPの使用方法に関する一連のルールにすぎないことが明らかになりました。したがって、私はこれらの規則の利点が何であるかについてフォローアップを投稿しました。 注:RESTの意味を理解しました。エミールイワノフのあることを意味していますHTTPの方法を使用して発言、REST手段。しかし、これが独自の用語に値するかどうかはわかりませんし、確かに誇大宣伝はありません。
303 http  rest 

7
RESTネストリソースのベストプラクティスは何ですか?
私の知る限り、個々のリソースには正規パスが1つだけ必要です。次の例では、適切なURLパターンは何でしょうか? 例として、会社の残りの表現を取り上げます。この架空の例では、各会社が 0以上の部門を所有し、各部門が 0以上の従業員を所有しています。 関連する会社がなければ、部門は存在できません。 従業員は、関連する部門なしでは存在できません。 これで、リソースパターンの自然な表現がわかります。 /companies 会社のコレクション -新しい会社のプットを受け入れます。コレクション全体を手に入れよう。 /companies/{companyId}個々の会社。GET、PUT、DELETEを受け入れる /companies/{companyId}/departments新しいアイテムのPOSTを受け入れます。(社内に部門を作成します。) /companies/{companyId}/departments/{departmentId}/ /companies/{companyId}/departments/{departmentId}/employees /companies/{companyId}/departments/{departmentId}/employees/{empId} 制約を考えると、各セクションでは、少し深く入れ子にするとこれは理にかなっていると感じます。 ただし、GETすべての会社のすべての従業員をリスト()にしたい場合、問題が生じます。 そのためのリソースパターンは、/employees(全従業員のコレクション)に最も密接にマッピングされます。 それは、/employees/{empId}もしそうなら、同じリソースを取得するための2つのURIがあるので、私も持っている必要があるということですか? または、スキーマ全体をフラット化する必要があるかもしれませんが、それは従業員がネストされたトップレベルのオブジェクトであることを意味します。 基本レベルで/employees/?company={companyId}&department={deptId}は、最も深くネストされたパターンとまったく同じ従業員のビューが返されます。 リソースは他のリソースによって所有されているが、個別にクエリ可能でなければならないURLパターンのベストプラクティスは何ですか?
301 rest  api-design 

4
cURLを使用してCookieを送信する方法
私はcurlでSend cookieが機能することを読みましたが、私には違います。 私はRESTエンドポイントを持っています: class LoginResource(restful.Resource): def get(self): print(session) if 'USER_TOKEN' in session: return 'OK' return 'not authorized', 401 私がアクセスしようとすると: curl -v -b ~/Downloads/cookies.txt -c ~/Downloads/cookies.txt http://127.0.0.1:5000/ * About to connect() to 127.0.0.1 port 5000 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0) > GET …

11
APIページネーションのベストプラクティス
私が作成しているページ分割されたAPIを使用して、奇妙なエッジケースを処理するのに役立ついくつかのものが欲しいです。 多くのAPIと同様に、これは大きな結果をページ分割します。/ foosに対してクエリを実行すると、100の結果(つまり、foo#1-100)と、foo#101-200を返す/ foos?page = 2へのリンクが表示されます。 残念ながら、APIコンシューマが次のクエリを実行する前にfoo#10がデータセットから削除された場合、/ foos?page = 2は100だけオフセットされ、foos#102-201を返します。 これは、すべてのfooをプルしようとしているAPIコンシューマーの問題です-foo#101を受信しません。 これを処理するためのベストプラクティスは何ですか?できる限り軽量化したい(つまり、APIリクエストのセッションの処理を避けたい)。他のAPIの例をいただければ幸いです。

7
RESTful APIで多対多の関係を処理する方法は?
PlayerとTeamの 2つのエンティティがあり、プレーヤーが複数のチームに所属しているとします。私のデータモデルでは、各エンティティのテーブルと、関係を維持するための結合テーブルがあります。Hibernateはこれをうまく処理できますが、この関係をRESTful APIでどのように公開できますか? いくつかの方法を考えることができます。最初に、各エンティティに他のエンティティのリストを含めることができるため、Playerオブジェクトには所属するチームのリストがあり、各チームオブジェクトには所属するプレーヤーのリストがあります。そのため、プレーヤーをチームに追加するには、プレーヤーの表現をエンドポイントにPOSTします。たとえば、POST /playerやPOSTのよう/teamに、リクエストのペイロードとして適切なオブジェクトを指定します。これは私にとって最も「RESTful」なようですが、少し変な感じがします。 /api/team/0: { name: 'Boston Celtics', logo: '/img/Celtics.png', players: [ '/api/player/20', '/api/player/5', '/api/player/34' ] } /api/player/20: { pk: 20, name: 'Ray Allen', birth: '1975-07-20T02:00:00Z', team: '/api/team/0' } これを行うために私が考えることができるもう1つの方法は、それ自体がリソースとして関係を公開することです。そのため、特定のチームのすべてのプレーヤーのリストを表示するには、GET /playerteam/team/{id}などを実行して、PlayerTeamエンティティのリストを取得します。プレーヤーをチームに追加するに/playerteamは、適切にビルドされたPlayerTeamエンティティをペイロードとしてPOST します。 /api/team/0: { name: 'Boston Celtics', logo: '/img/Celtics.png' } /api/player/20: { pk: 20, name: 'Ray Allen', birth: …

21
改造リクエストの本文に未加工のJSON全体をPOSTする方法は?
この質問は以前に尋ねられた可能性がありますが、明確に回答されていませんでした。Retrofitリクエストの本文内に未加工のJSON全体をどのように正確にポストしますか? ここで同様の質問を参照してください。または、この回答は、URLエンコードされてフィールドとして渡される必要があることは正しいですか?私が接続しているサービスは投稿の本文にそのままのJSONを期待しているだけなので、私は本当に望みません。JSONデータの特定のフィールドを検索するように設定されていません。 私はちょうどでこれを明確にしたいrestpertsきっぱりと。一人はレトロフィットを使用しないと答えました。もう1つは構文が明確ではありませんでした。別の人はそれが可能であると考えていますが、そのフォームがURLエンコードされてフィールドに配置されている場合のみです(私の場合は受け入れられません)。いいえ、Androidクライアントのすべてのサービスを再コーディングすることはできません。そしてはい、JSONコンテンツをフィールドプロパティ値として渡すのではなく、未加工のJSONをポストすることは、主要なプロジェクトでは非常に一般的です。それを正しく理解して次に進みましょう。これがどのように行われるかを示すドキュメントまたは例を誰かが指すことができますか?または、それができる/すべきではない正当な理由を提供してください。 更新:100%確実に言えることの1つ。Googleのボレーでこれを行うことができます。内蔵されています。これをレトロフィットで実行できますか?

9
動詞なしでREST URLを作成する方法は?
安らかなURLを設計する方法を決定するのに苦労しています。動詞がこれを行う方法を理解していない、名詞とURLを使用する安らかなアプローチに私はすべて賛成です。 財務計算機を実装するサービスを作成しています。計算機は、CSVファイルを介してアップロードする一連のパラメーターを受け取ります。ユースケースには以下が含まれます。 新しいパラメータをアップロードする 最新のパラメーターを取得する 特定の営業日のパラメーターを取得する パラメータのセットをアクティブにします 一連のパラメーターを検証する 私は、次のタイプのURLを持つことで、安静なアプローチを収集します。 /parameters /parameters/12-23-2009 最初の3つの使用例は、次の方法で実現できます。 ポストリクエストにパラメータファイルを含めるPOST 最初のURLのGET 2番目のURLのGET しかし、動詞なしで4番目と5番目のユースケースをどのように実行しますか?次のようなURLは必要ではないでしょうか。 /parameters/ID/activate /parameters/ID/validate ??
283 rest  restful-url 

13
@QueryParamと@PathParamを使用する場合
私はすでにここで質問されている質問をしていません: @PathParamと@QueryParamの違いは何ですか これは「ベストプラクティス」または規則の質問です。 するときは、使用する@PathParam対@QueryParam。 その決定は、情報パターンを区別するために2つを使用することであると考えることができます。私のLTPOを以下に説明します-完全ではありません。 PathParamの使用は、情報ツリーのブランチにうまく分類される情報カテゴリに予約できます。PathParamを使用して、エンティティクラス階層にドリルダウンできます。 一方、QueryParamは、クラスのインスタンスを見つけるための属性を指定するために予約できます。 例えば、 /Vehicle/Car?registration=123 /House/Colonial?region=newengland /category?instance @GET @Path("/employee/{dept}") Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ; 対 /category/instance @GET @Path("/employee/{dept}/{id}") Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ; 対 ?category+instance @GET @Path("/employee") Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ; それを行うための標準的な慣習はないと思います。ある?しかし、私が上で例示したように、人々がどのようにPathParamとQueryParamを使用して彼らの情報を区別するかについて聞きたいです。練習の理由も聞きたいです。
276 java  rest  jax-rs 

6
REST APIでPATCHまたはPUTを使用する必要がありますか?
次のシナリオに適した方法で残りのエンドポイントを設計したいと思います。 グループがあります。各グループにはステータスがあります。グループは、管理者がアクティブ化または非アクティブ化できます。 エンドポイントを次のように設計する必要がありますか PUT /groups/api/v1/groups/{group id}/status/activate または PATCH /groups/api/v1/groups/{group id} with request body like {action:activate|deactivate}


4
無効なデータのREST応答コード
以下のシナリオの場合、クライアントにどの応答コードを渡す必要がありますか? 間違ったメール形式のようにユーザー登録中に無効なデータが渡されました ユーザー名/メールアドレスは既に存在します 403を選びました。また、使用できると感じたのもわかりました。 ウィキペディア: 412前提条件が失敗しました:サーバーは、要求者が要求に入力した前提条件の1つを満たしていません 403以外を使用する必要がある場合は、コードを提案してください。
272 http  rest  jax-rs 

12
パラメータ付きSpring RestTemplate GET
RESTカスタムヘッダーとクエリパラメーターを含む呼び出しを行う必要があります。HttpEntityヘッダーのみ(本文なし)を設定し、RestTemplate.exchange()メソッドを次のように使用します。 HttpHeaders headers = new HttpHeaders(); headers.set("Accept", "application/json"); Map<String, String> params = new HashMap<String, String>(); params.put("msisdn", msisdn); params.put("email", email); params.put("clientVersion", clientVersion); params.put("clientType", clientType); params.put("issuerName", issuerName); params.put("applicationName", applicationName); HttpEntity entity = new HttpEntity(headers); HttpEntity<String> response = restTemplate.exchange(url, HttpMethod.GET, entity, String.class, params); これは、クライアント側で失敗し、dispatcher servletハンドラーへの要求を解決できません。デバッグしたところ、リクエストパラメータが送信されていないようです。 POSTリクエスト本文を使用し、クエリパラメータを使用せずに交換を行うと、問題なく機能します。 誰かが何かアイデアを持っていますか?
267 java  spring  rest 

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