» REST 入門 目次 前回、はてなブックマークを例にリソースと四つの HTTP メソッド (GET, POST, PUT, DELETE) の関係について解説しました。 今回は、リソース同士をどのように関連付けるか、について解説します。 前回の記事でこんな疑問を持った人はいなかったでしょうか。 ひとつのブックマークリソースにいろいろなメソッドを適用しているけれど、 そのブックマークリソースにはいったいどうやってたどり着くのか。 たとえば PostURI に POST して新規作成したブックマークを全部覚えておけば、 それぞれのリソースの URI はわかります。 しかしそれではソーシャルブックマークサービスを使う意味がありません。 ローカルディスクまたはローカルサーバに保存しておくのではブックマークを共有することができないし、 そもそも自分以外の人のブックマークにアクセスできないのでは、
HTTPプロトコルでは、コンピュータ同士が通信している間に、コードを用いてお互いの状態(ステータス)をやり取りしています。このコードのことをHTTPステータス・コード(HTTP Status Code)と呼び、エラーが発生した場合に「404 Not Found」のようにブラウザ上に表示されたり、エラーが発生しなかった場合にも見えないところでやり取りされています。 また、通信を行うためにクライアントがサーバーに様々なリクエストを行いますが、このリクエストの方法をメソッドと呼びます。 規格
Ruby でよく使うライブラリ net/http なんですが,コネクション張り続けて通信するにはどうしたらいいんだろう.という話. いろいろ弄った結果 ポイントは二つくらい 念のため Net::HTTP:Get のインスタンスに以下のようなヘッダエンティティtをくっつける. Net::HTTP::Get#['Connection'] = 'Keep-Alive' Net::HTTP.start や,Net::HTTP#start を使ってコネクションを張る 2回目以降の要求をする時において,前回の要求から時間が空いていると,サーバがコネクションを断ち切ってしまうので,コネクションの張り直し手続きが必要になる.これらを踏まえて,3回ほど d.hatena.ne.jp に要求を送るスクリプトを書く. また3回目の要求の際は,意図的に間隔を空けて,サーバからコネクションを断ち切られてしまった場合
通常、HTTP リクエストは、次のリクエストは完全に受け取られた現在のリクエストに対するレスポンスのあとにだけ発行されるという形で、連続して発行されます。ネットワークの待ち時間と帯域幅の制限により、次のリクエストがサーバによって受け取られるまでに、著しい遅れを生じさせることもあります。 HTTP/1.1 では、複数 HTTP リクエストを対応するレスポンスを待つことなくソケットに同時に書き出すことを許しています。リクエスト発行者は、リクエストされた順序での到着のためのレスポンスを待っています。リクエストの「パイプライン化」の作用でページ読み込み時に劇的に改善をみせることもあります。高い待ち時間をともなう接続においては特にそうです。 パイプライン化はまた、TCP/IP パケットの数を劇的に減少させることもあります。536 ~ 1460 バイトの典型的な MSS (最大セグメントサイズ) で、
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Basic 認証において、ユーザ名とパスワードを送信する方法を説明します。 まずユーザ名とパスワードをコロンで結合します。 もしユーザ名「hoge」、パスワード「fuga」の場合、「hoge:fuga」という文字列を作るわけです。 それを BASE64 でエンコードします。 「hoge:fuga」を BASE64 エンコードすると「aG9nZTpmdWdh」となります。 UNIX のコマンドでは、以下のようにして確認できます。 % echo -n 'hoge:fuga' | base64 -e % echo -n 'hoge:fuga' | openssl enc -e -base64 % echo -n 'hoge:fuga' | nkf -MB % echo -n 'hoge:fuga' | perl -MMIME::Base64 -ne 'print encode_base64($_
HTTPステータスコードの302はMoved Temporarilyだと思っていたのですが、RFC 2616(Hypertext Transfer Protocol — HTTP/1.1)で『302 Found』に改められていました。そして、RFC 2616では『307 Temporary Redirect』というステータスコードが追加されていました。 『302 Found』と『303 See Other』と『307 Temporary Redirect』の違いについて気になったので、まとめてみました。 元々、ステータスコード302はMoved Temporarilyでした。『302 Moved Temporarily』とは、「指定したURIのリソースは、一時的に別のURIに存在しているので、そちらを参照してください」と言う意味です。もちろん一時的に別のURIに存在しているため、クライアン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く