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

現在、CSSメディアクエリを使用したレスポンシブウェブサイトを開発しています。サーバーがビューポートごとに異なるHTML / CSSを返すと、はるかに簡単になります。 クライアントがHTMLファイルをリクエストするときにビューポート情報を含めることができないのはなぜだろうと思っていました。この動作は、Accept-Languageヘッダーを使用して正しい言語でWebサイトを返す場合にすでに一般的です。

10 http 

Acceptクライアントからのヘッダーの目的は、サーバーが要求への応答として受け入れるデータの種類を通知することです。このヘッダーは、JavaScriptの非同期HTTP呼び出しで設定できますが、HTMLでは設定できません。 たとえば、のようなリンクを考えてみましょう<a href="https://softwareengineering.stackexchange.com/some/resource">Get as CSV</a>。のような属性accept="text/csv"が許可されていて、ブラウザAccept: text/csvがそのリクエストと共にヘッダーを送信すると解釈した場合、サーバーはリクエストのセマンティクスに応答できます。それがなければ、などのリンクを作成する可能性が<a href="https://softwareengineering.stackexchange.com/some/resource?format=csv">Get as CSV</a>あり、サーバーは代わりに任意のクエリ文字列パラメーターに応答する必要があります。 Acceptマークアップによるヘッダーの設定を許可しないHTML \ DOM仕様の背後にある技術的および歴史的な理由は何ですか？

10 history  http  specifications 

REST [api]構造とOOモデルを比較すると、次のような類似点があります。 どちらも： データ指向ですか REST =リソース OO =オブジェクト データを取り巻く操作 REST =リソースをVERBS（Get、Postなど）で囲みます OO =カプセル化によってオブジェクトの周りの操作を促進する ただし、適切なOOプラクティスは、たとえばファサードパターンを適用しようとするときにREST APIに常に依存しているわけではありません。RESTでは、すべてのリクエストを処理する1つのコントローラーがなく、内部オブジェクトの複雑さを隠しません。 それどころか、RESTは、少なくとも2つの形式で、リソースとその他のすべての関係のリソース公開を促進します。 リソース階層関係を介して（id 43の連絡先はアドレス453で構成されます）： /api/contacts/43/addresses/453 REST json応答のリンクを介して： >> GET /api/contacts/43 << HTTP Response { id: 43, ... addresses: [{ id: 453, ... }], links: [{ favoriteAddress: { id: 453 } }] } OOに戻ると、ファサードの設計パターンLow Couplingは、objectAとその「objectBクライアント」の間、およびHigh CohesionこのobjectAとその内部オブジェクト構成（objectC、objectD）を尊重します。とをObjectAのインターフェースは、これは、許可に制限の影響に現像剤をObjectBのObjectAに（内部変化ObjectCに及びobjectD長いほど）、ObjectAにする API（操作）が依然として尊重されます。 …

9 http  rest  definition 

私はサーバーと多くのクライアント（約50クライアント）がWebアプリケーションに基づいてそのサーバーに接続するクライアントを持っています。これはもちろん、HTTPプロトコルに基づいており、TCP / IPを使用しています（間違っている場合は修正してください。ネットワーキングは本当に得意ではありません）。 問題は、私が警告メカニズムを開発する必要があることです。誰かが危険な値を含むフォームを送信すると、マネージャー（同じWebアプリケーションを介して接続されている）が彼の画面に警告ポップアップを受信します。 -time（瞬時に）。 ただし、HTTPプロトコルはステートレスなので、ここでは少し戸惑います。これを実装する方法がわかりません。 ソリューションの1つは、JavaScriptをsetInterval()関数と一緒に使用して、サーバーから毎秒データをプルすることです。しかし、これは私には少し汚く、専門家ではないようです。 別のソリューションを実装するアイデアはありますか？

9 web-development  design-patterns  http  observer-pattern 

基本的に、私のアプリの1つの機能は、ログに記録されたユーザーの友達を取得することです。 実際、私は両方の種類のエンドポイントの間で迷っています： GET / api / users / friends GET / api / users /：userId / friends 1を使用userIdすると、認証トークンを通じて到達可能になります。 2を使用すると、サーバーは、渡さuserIdれたと、認証トークンで指定されたログに記録されたユーザーIDとの対応をさらにチェックして、友達などの他のユーザーデータへの悪意のあるアクセスを回避する必要があります。 したがって、1で十分ですが、標準のレストURLのようには聞こえません。 良い習慣とは何ですか？

9 rest  http  authentication  url 

私が作成しているAPIにHTTPリクエストを行うサードパーティは、APIが1秒未満で応答することを要求しています。私の質問は、彼らが道持っているされて（文字通りあらゆるの範囲内で、道をHTTPおよび/またはTCP / IPプロトコル）それは長い1秒以上かかる場合は、私のコードの実行を中止するには？

8 c#  api  asp.net  http  asp.net-core 

広告キャンペーンのトラッカーデータをリクエストできる広告配信プラットフォーム用のAPIを構築しています。多くの場合、キャンペーンは数億のリクエストを超えるため、テラバイトに相当するデータが大量に存在します。したがって、APIの利用者が一度に大量のデータをリクエストすること（リクエストがタイムアウトするなど）を防ぐ必要がありますが、それを行うためのベストプラクティスが何かはわかりません。 私がすでに特定したオプションは次のとおりです。 データのどのセクションが必要かを示す追加のパラメーターをリクエストに追加する データを切り捨て、どういうわけか、より具体的なフィルターを使用する必要があることをクライアントに伝えます HTTPステータスコード413で応答します（ただし、これは応答ではなく、大きなリクエスト本文のようです） ストリーミングAPIへの切り替え（TwitterのストリーミングAPIなど） しかし私の質問は、このような状況に対する標準的な実践/適切な対応は何ですか？ 注：DoS攻撃はパブリックAPIではないため、それほど心配する必要はありません。

8 database  rest  http  ajax  scalability 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 PHPからASP.NETに変更しましたが、今はやや大規模な会社でWebフォームを使用しています。しかし、ASP.NET Webフォームに関する印象を裏付けるためにいくつか調査を行い、Webフォームは「デスクトッププログラミング」の世界から来た人のためにWebアプリケーションを簡単に作成できるようにするための試みであるという結論に達しました。 しかし、私はWebフォームを回避する前に、私たちが作成したソフトウェアのニーズを分析することを決定し、Web上のアプリケーションの状態を維持する問題にぶつかりました。 HTTPはステートレスプロトコルであり、ASP.NETはセッション変数、hiddenfields、viewstatesを使用して状態をシミュレートしようとしていることを理解しています。上記のすべてに欠陥があり、状態を維持するのに完全ではないことも理解していますアプリケーションですが、アプリの状態を維持する必要性も理解しています。 どちらが問題を提起しますか、HTTPはこのタイプのジョブ（状態を必要とするアプリケーションの作成）に本当に適していますか？現在、ツールはWeb開発者が利用できますか？HTML5で利用できる新しいツールは仕事で効果的ですか、それともHTTPの制限に対する回避策にすぎませんか。 私はWeb用に開発するのが大好きで、デスクトップよりもWebに精通しています。このHTTPのステートレス性についてしばらく疑問に思っていたので、ポイントが足りないのか、それともm私の考えにぴったりです。

8 web-applications  html5  http  webforms 

RESTfulな観点から、（StackExchangeのような）フォーラム投稿を賛成するアクションに最も適切なHTTPメソッドは何ですか？ 投票の場合はPOSTを、投票を取り消す場合はDELETEと言いますが、ユーザーはメッセージごとに1つの票を投じることしかできないため、投票はべき等演算と見なすことができるため、PUTも可能です。

8 rest  http  semantics 

ほとんどのWebサイトは、ロゴ画像などの静的アセットmax-age=31536000のCache-controlヘッダーを設定します（1年）。例： YouTube ヤフー ツイッター BBC ただし、注目すべき例外があります。Googleのロゴにはmax-age=6912008日間あります。 私は過去にGoogleロゴのヘッダーを確認しましたが、以前は間違いなく1年でした。（また、以前はスプライトの一部でしたが、現在はスタンドアロンのロゴ画像ですが、おそらく別の質問です...） キャッシュの有効期間をわずか8日間に減らしたいと思う正当な技術的理由は何でしょうか？Googleのホームページは、世界で最も慎重に最適化されたページの1つなので、正当な理由があると思います。 編集： 回答する前に、これらの点を理解しておいてください。 max-age静的アセットを将来変更できるようにするために、短いライフタイムを使用する人はいません。変更する場合は、別のURLで提供するだけです。いいえ、Google Doodleとは関係ありません。考えてみてください。GoogleがこのHTTPの基本的なトリックを理解していなかったとしても、元のロゴがキャッシュされていないユーザーだけがdoodle-dayにDoodleを目にするため、8日間は適切ではありません。そのユーザーグループは、GoogleがDoodleを変更してから8日間、Doodleを見続けていました:) Webサーバーはクライアント（またはプロキシ）のキャッシュを「いっぱいにする」ことを心配していません。クライアントは自分でこれを管理します。自身のストレージ制限に達すると、優先度が最も低いアイテムをドロップし始め、新しいアイテムのためのスペースを作ります。優先度スコアは、「このURLをキャッシュしたことによるメリットはどれくらいありますか？」という質問に基づいています。これはmax-age、URLが最初に要求されたときにサーバーが送信した値とは関係ありません。これは、「頻度」に基づくヒューリスティックです。そのURLに対するリクエストの数です。max-age単にサーバーがカットオフポイントを設定できるようにします。これは、アイテムが再利用される頻度に関係なく、クライアントがアイテムを破棄することになっている時間です。ダウンストリームのクライアント/プロキシがキャッシュをいっぱいにするのを「控え」に頼るのは、とてもいい信頼できることですが、私たちはその世界に住んでいるとは思いません;）

8 caching  http  front-end 

この質問はこれに触発されました。SOAPを発明する最初の目標は何でしたか？古い種類のHTTPとRESTがあったときになぜ発明されたのですか？

8 rest  http  soap 

RESTサービスでは、すべての応答で一意のリクエストIDを送り返したいと思います。内部プロジェクトのデバッグに役立つだけでなく、将来サービスを使用する可能性のあるサードパーティにサポートを提供する場合にも役立ちます。 すべてのRESTリクエストがレスポンスボディになる必要があるわけではないため（多くの場合、低レベルのREST APIはステータスコードと説明のみを利用します）、このリクエストを送り返す必要があるため、レスポンスヘッダーを使用する必要があると判断しました。 ID。 可能であれば、途中でプロキシによって取り除かれる可能性が低い HTTP応答ヘッダーを使用するようにします。 多数のクライアントがモバイルデバイスであり、クライアントとサーバー間の「興味深い」ネットワークトポロジにバインドされているため、これは非常に重要です。 ただし、同じサービスが、自社のファイアウォール/プロキシを使用する他の企業にも販売される可能性があります。 このため、よく知られているヘッダーの代わりにカスタム応答ヘッダーを使用するという考えを根本的に覆いました。 私の現在の優勝既知のヘッダーはETagヘッダーですが、それはほぼ正しいですが、それは完全ではありません- ETagはリソース用であり、リクエストではありません（つまり、同じリソースに対する2つの別々のリクエストは合法的に同じを返しますETag）。さらに、それを使用すると、エンティティタグを他の目的で実行できないことを意味します。 誰か良いアイデアはありますか？ 更新 Pragmaヘッダーは使用されているように見えますが、Asp.Net WebAPI内での書き込みに問題があります。 SOに関する関連質問です。

8 web-services  rest  http