HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
RFCは、なぜ「意見募集」という名前だったのか？:Geekなぺーじ
インターネットで使われる各種仕様の多くは、RFCと呼ばれる文書として発行されています。 RFCは、「意見募集」や「意見を求む」といった意味を持つRequest For Commentsの略ですが、インターネットに関連する通信仕様の標準を示す文書の名称が、なぜ意見を募集するとなっているのでしょうか？ それには、初期のRFCが発行された時代背景があるのです。 RFCの文書番号は新しい文書とともに増加していくので、基本的に文書番号が小さいほど昔のものになります。 最初のRFCである、RFC 1は、1969年4月7日に発行されています。 多少余談になりますが、RFC 1は、「インターネット」という単語が生まれる前に発行されています。 「インターネット（internet）」という単語が初めて登場するRFCは、1974年に発行されたRFC 675です。 1973年に発行されたRFC 604とRFC 6
<?phpタグが無くなる日 〜PHPの開発プロセス〜
PHPスクリプトを記述する際に使われる<?phpタグの利用をオプションで有効無効を切り替えるようにするという仕様がPHPの開発コミュニティでの議論に挙がっています。 この仕様変更が実装された場合、PHPスクリプトには必ず<?phpのタグがあるという前提条件が変わる事になります。 まずこの議論がどのような形で行われているのでしょうか？ご存知でない方もいるかと思いますが、PHPの文法や機能へどのような変更を加えたいか、という議論はRFC (Request For Comment)という形でパブリックに行われています。Wikiページに仕様や背景、実際のパッチなどを添付し、開発者やユーザーからの投票を行った結果を元に実際にPHP本体への変更を行うかどうかが決定されています。 過去に実装された機能の際の例などと一緒に見てみましょう。 Array Short Syntax # 従来の記述の場合 $a
「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる, 「エンジニアのためのイベント映像活用方法」の第2回が gihyo.jp に掲載されました - 雑文発散(2013-01-24)
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。（多用されているかはともかく）Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
ついにRFCに登場！Webサーバとの双方向通信を実現する「WebSocket」 - builder
次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard（RFC 6455）となった。 AjaxからComet、そしてWebSocketへ WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC7085: Top-Level Domains That Are Already Dotless
RFC Sourcebook