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

WebApiを使用してRESTful Webサービスを設計していますが、オブジェクトの更新/作成時にどのHTTP応答と応答本文を返すのか疑問に思っていました。 たとえば、POSTメソッドを使用してJSONをWebサービスに送信し、オブジェクトを作成できます。HTTPステータスをcreated（201）またはok（200）に設定し、「New Employee added」などのメッセージを返すか、元々送信されたオブジェクトを返すのがベストプラクティスですか？ 同じことがPUTメソッドにも当てはまります。どのHTTPステータスを使用するのが最適で、作成されたオブジェクトまたはメッセージだけを返す必要がありますか？とにかくユーザーが作成/更新しようとしているオブジェクトを知っているという事実を考慮してください。 何かご意見は？ 例： 新しい従業員を追加： POST /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Name" : "Joe Bloggs", "Department" : "Finance" } } 既存の従業員を更新します。 PUT /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Id" : 1 "Name" : "Joe Bloggs", "Department" : "IT" } …

36 rest  http 

次の形式のURLがあります / instance / {instanceType} / {instanceId} 標準のHTTPメソッドで呼び出すことができます：POST、GET、DELETE、PUT。ただし、「下書きとして保存」や「キュレート」など、いくつかのアクションがあります ドラフト、検証、キュレートなどのカスタムHTTPメソッドを使用できると考えました 基準が言うので、これは許容できると思います 「HTTP / 1.1の共通メソッドのセットを以下に定義します。このセットは拡張できますが、追加のメソッドは、個別に拡張されたクライアントとサーバーで同じセマンティクスを共有することはできません。」 また、WebDavなどのツールは独自の拡張機能を作成します。 カスタムメソッドで誰かが遭遇した問題はありますか？プロキシサーバーとファイアウォールを考えていますが、他の懸念事項は大歓迎です。安全な側にとどまり、action = validate | curate | draftのようなURLパラメーターを設定するだけですか？

34 rest  http 

HTTP API応答に関する何らかの標準はありますか？ この談話スレッドを読んだ後、私は疑問に思い始めました。私の仕事ではパブリックHTTP JSON APIを開発していますが、厳密に必要でない場合は何も返しません（たとえば、/ resource / {id}へのPUTは、OKまたは対応する4XXまたは5XXコードのときに200のみを返しますが、 JSON本体） {"success":true}上記のリンクで説明したようなジェネリックを返す必要がありますか、それとも「void」ボディを返してすべてをhttp応答コードで処理しても大丈夫ですか？

33 rest  api-design  http 

IPアドレスを介してCookieを使用することでいくつかの追加の利点があることはわかっていますが、私の質問は、クライアントがサイトに再度アクセスしたときにクライアントを識別する際にクライアントのIPアドレスを記憶できないのはなぜですか？コンテナがIPアドレスを使用してクライアントを記憶することは可能ですか？

26 http  session  networks  cookies  client-server 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 HTTPベースのAPIと呼び、URIを使用してリソースとHTTP動詞（PUT、POST、DELETE、GET ...）に名前を付け、それらのリソースを操作しますか？ ロイ・フィールディングの苦情によると、ハイパーメディアがないため、RESTではありません。 内部的には、私のチームでは、誰もが「REST API」と呼んでいます。私はそれを「RESTライク」と呼んでいますが、説明的ではなく、その意味はあいまいです。RESTについては大きな意見の相違があるため、私はそれについてかなり混乱しています。火炎戦争に参加したくないのですが、正しい用語を使用してください。

24 terminology  rest  api  http 

この質問は、Software Engineering Stack Exchangeで回答できるため、Server Faultから移行されました。 6年前に移行され ました。 私は現在、初めてのHTTP APIを実装しています。 適切な状況に適切なコードを実装することを決心しているため、HTTPステータスコードのウィキペディアページを見るのに多くの時間を費やしてきました。そのページには、420のコードがリストされています。これは、Twitterがレート制限に使用していたカスタムコードです。 ただし、すでにレート制限のコードがあります。429です。 これにより、ユースケースが既に存在するのに、なぜカスタムに設定するのか疑問に思いました。それはただかわいいだけですか？もしそうなら、異なる状況コードを返すことがどのような状況で受け入れられるようになりますか？また、クライアントに問題がある場合はどうなりますか？ Mozillaがジョーク418: I’m a teapot応答を実装していないことをどこかで読んだので、クライアントは実装するステータスコードを選択すると思います。それが本当なら、Twitterの面白おかしい小さなコードがあなたの落ち着いたコードの問題を改善していると想像できます。 誤解しない限り、任意のコード番号を使用して好きなものを意味することができます。この規約では、404が見つからないことを意味し、429は簡単にすることを意味します。

24 api-design  http 

私はRESTful APIの開発により深く取り組み、これまでにいくつかの異なるフレームワークと連携してこれを実現してきました。もちろん、私は同じ起源のポリシーに遭遇しましたが、今では（Webブラウザーではなく）Webサーバーがどのようにそれを実施するのかと思っています。私が理解していることから、ブラウザの最後にいくつかの強制が行われているようです（たとえば、サーバーから受信したAccess-Control-Allow-Originヘッダーを尊重します）。しかし、サーバーはどうですか？ たとえば、WebサーバーがAPIにアクセスするJavascript Webアプリをホストしており、そのサーバーでもホストされているとします。私は、サーバーが同一生成元ポリシーを適用すると想定しているため、そのサーバーでホストされているJavaScriptのみがAPIにアクセスできるようになります。これにより、他の誰かがそのAPIのjavascriptクライアントを記述して別のサイトでホストすることを防ぐことができますか？それでは、Webサーバーは、同じWebサーバーから発信されたjavascriptを実行していると主張しながら、APIエンドポイントにAJAXリクエストを行おうとする悪意のあるクライアントをどのように停止できますか？最も一般的なサーバー（Apache、nginx）は、この種の攻撃からどのように保護しますか？または、これについての私の理解は何とか外れていますか？ または、クロスオリジンポリシーはクライアントエンドでのみ実施されますか？

24 web-development  security  ajax  http  xmlhttprequest 

ユーザーが常にいくつかの「プラン」のいずれかを使用するプロジェクト用のREST APIを設計しています。各プランは、アカウントに含めることができるユーザーの最大数やアップロードできるデータの最大数など、リソースの制限を定義します。これらの制限の1つに達すると、ユーザーはプランをアップグレード（基本的に支払い）して、より多くのリソースを取得できます。 アカウントのリソース制限のためにアクションを実行できない状況を示す特別なステータスコードを返します。プランをアップグレードすると解決します-たとえば、ユーザーがストレージ容量の100％を使用して追加のファイルをアップロードしようとした場合、彼らはこの応答を受け取ります。 候補者は次のとおりです。 403 Forbidden -ただし、このケースと、ユーザーがこのアクションを実行するための許可を単に持たない他のケースとを区別したいと思います。 401 Unauthorized -良いアイデアではありません。認証関連の問題にこれを使用しています。 402 Payment Required -ある意味理にかなっていますが、標準ではないが予約済みのステータスコードの使用が心配です 423 Locked将来的には他のものに使用する可能性が低いため、さらに標準以下のもの 別のオプションは、非常に標準的なもの403を使用することです。ただし、応答本文にエラーの詳細を示します。 どのアプローチが（a）長期的に最も効果的であり、（b）RESTfulな原則にもっとうまく適合すると信じているのか疑問に思っています。

24 rest  api-design  http 

製品、ブログ投稿など、リソースのデータベースがあります。パブリックWebサイト用に、それらに対処するURLスキームを設計する必要があります。 データベースIDがバインドされている2つの例を次に示します。 https://www.youtube.com/watch?v=7FPS6llqhXw http://www.amazon.co.uk/gp/product/B000NHOMSQ わかりやすい例は次のとおりです。 http://en.wikipedia.org/wiki/LED_circuit （そこでのブラウジング生活を少し垣間見ます） メールまたはドキュメントでホバーまたは表示するときにURLの末尾に何があるかを知っているので、わかりやすいURLが好きです。SEOの方が良いか、以前はそうでした。 ドキュメントまたは製品の名前が変更されるとどうなりますか？変更された（Wikiは変更されないかもしれませんが、リソースは変更される可能性があります）か、タイプミスのためですか？私たちのリソースは非常に技術的で、長い言葉であり、間違いを起こしやすいものです。 また、数値であるデータベースIDがあります。仮装レンタルストアを使用して、ビデオのアドレスのアイデアを見てみましょう。 http://vidsyeah.com/video/sliding-doors/287171 IDは明らかであり、DBルックアップで使用されます。いいよ スライドドアビットは一意ではなく、ビデオタイトルから生成されただけで、GETで検証できます。したがって、スライドドアが入力され、doc 287171に実際にあるものと一致しない場合、404と応答します。 あるいは、誰かが気にかけた場合、人間が好きなものをそこに貼り付けることができるようにすることもできます。したがって、このURLも機能します。 http://vidsyeah.com/video/anything-at_all/287171 友好的な部分を検証する際の問題は、前述のように、名前の変更またはタイプミスの修正の問題です。名前が変更され、ドメイン内で実際に発生した場合、そこにあるURLを壊したくないので、次のようにします。 友好的な部分を確認しないでください。 確認しますが、以前のフレンドリIDが引き続き機能するように、フレンドリパーツの「履歴」をデータベースレコードに追加します。 あなたの考えやアイデアは大歓迎です。 ルカ

24 web-applications  rest  web  websites  http 

インターネットで一番かわいい猫をランク付けしている会社があるとしましょう。 /cats/ユーザーに最新のかわいい猫を提供するリソースを提供します。 ユーザーは、支払いを行っていないか登録していない場合、上位3匹の猫のみを取得できます。337ドルを支払ってログインしている場合は上位10匹の猫、1337ドルを支払ってログインしている場合は上位100匹の猫。リクエストを行うときに「ユーザーID」があります。 要するに、消費者は/cats/「ユーザーランキング」に基づいて異なる数の猫を取得します。消費側にはユーザー識別子がありますが、消費側にはユーザーレベルの明示的な表現はありません。リクエストを行うときにサブスクリプションをアップグレードできることをユーザーに通知したいと思います。つまり、3匹の猫と3匹の猫しか提供していないため、3匹の猫を区別する必要があります。これは、ユーザーレベルで許可されているためです。 消費者が十分な特権を持っていないためにリソースを制限し、それが制限されていることを区別するためのベストプラクティスは何ですか？ クライアントは、ランキングをアップグレードできるかどうかをどのように知っていますか？それはので、彼らは限られたリソースを持っている彼らは権限がありません。ここでのベストプラクティスは何ですか？ これは実際のケースを大幅に単純化したものであることに注意してください。また、単に明確にするために-読んでいただければ幸いです。 更新： 検討したオプションは次のとおりです。 クライアントに一度ユーザー権限オブジェクトを保存し、アカウントのログインまたはアップグレードが実行されたときにのみ照会します。 null存在することを示す値をJSONで渡しますが、実際には何も転送されませんでした。したがって、3匹の猫を持つユーザーの場合、10匹の猫は["Garfield","Sylvester","Puss in Boots",null*7] リソース許可ペアを渡す {cats:["Whiskers","Fluffy","Socks"],authCount:3} 一番かわいい猫を可能な限り最良の方法で配達するために、初めてこれを正しく行いたいと思います。

23 rest  http  url  http-response 

だから私はGoogle App Engineアプリケーションの作成に取り組んでおり、「最初のアプリはHTTPベースのAPIを使用してオブジェクトを公開できる」、「このdatamodelクラスを公開する」など、何度も「公開」という用語に出くわしましたREST API」。「露出」とはどういう意味ですか？関連する特定のアクションがありますか、それとも設計の抽象的な部分ですか？

18 api  http  google-app-engine 

HTTPヘッダーでJWTトークンを使用して、リソースサーバーへのリクエストを認証しています。リソースサーバーと認証サーバーは、Azureの2つの独立したワーカーロールです。 トークンにクレームを保存するか、他の方法で要求/応答に添付するかについて、思いを固めることはできません。クレームリストは、サーバー上のデータへのアクセスだけでなく、クライアント側のUI要素のレンダリングにも影響します。このため、サーバーで受信したクレームが本物であり、リクエストが処理される前に検証されていることを確認したいと思います。 クレームの例：CanEditProductList、CanEditShopDescription、CanReadUserDetails。 JWTトークンを使用したい理由は次のとおりです。 クレームのクライアント側編集に対するより良い保護（クレームリストのハッキング）。 リクエストごとにクレームを調べる必要はありません。 JWTトークンを使用したくない理由： 次に、認証サーバーはアプリ中心のクレームリストを知る必要があります。 トークンは、ハックエントリの単一ポイントになります。 JWTトークンはアプリレベルのデータ用ではないことをいくつか読みました。 どちらにも欠点があるように思えますが、これらの主張をトークンに含めることに傾倒しており、これを以前に扱った人によって実行したいだけです。 注：すべてのAPIリクエストにHTTPSを使用するため、トークンは「十分」に安全であると思われます。私はAngularJS、C＃、Web API 2およびMVC5を使用しています。

18 security  http  authentication  authorization 

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 

ライブビデオをユーザーにストリーミングする必要があるWebサイトで作業しているため、現在のブラウザーベースのビデオストリーミングテクノロジーの残念な状態を回避する必要がありました。現在、ライブストリーミングの最も一般的なソリューションには互換性の問題があります。RTMPはFlashを必要とし、HLSはAndroidのSafariとChromeでのみネイティブにサポートされ、DASHはどこでもネイティブにサポートされず、dash.jsを使用するにはMedia Source Extensionsが必要ですが、これはまだ広くサポートされていません。 これは私には明らかな質問につながります：ブラウザーサポートまたはプラグインを必要とするHLS、RTMP、DASHのようなプロトコルの代替として単純なプログレッシブダウンロードを使用することは可能ですか？ プログレッシブダウンロードを使用してライブメディアをストリーミングするというアイデアは、これまでにないものではありません。人々はすでにオーディオのためにそれをしています。liveCasterなどのツールを使用すると、事前に記録されたMP3ファイルを必要とせずに、単一のプログレッシブHTTP応答を介してライブMP3オーディオをストリーミングできます。 しかし、ビデオでこの手法が実際に使用されている例は見たことがありませんが、その理由はわかりません。面倒で難しいブラウザ側の互換性の問題の層を比較的少ないトレードオフで削除するようです。（そして、ライブストリーミングの場合、プロが行っても互換性は依然として大きな問題です。FirefoxでBBCのiPlayerでライブビデオを視聴しようとすると、Flashをインストールするように指示するエラーメッセージが表示されます。）このテクニックは、私以外の誰もこのアイデアに言及するのを見たことがない。 どうして？生成されているプログレッシブダウンロードを介してMP4のようなビデオファイルをストリーミングし、ダウンロードしながら<video>要素で再生することを不可能にする根本的な制限はありませんか？

16 web-development  html  http  video