HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HttpServletResponse#getOutputStream()したストリームは自分でclose()するのか？
久々にJavaな話題。昨日社内で、 「Servletの中でresponse#getOutputStream()や#getWriter()したストリームは、自分でclose()する必要があるの？それともclose()せずに放置が正解なの？」 という質問を受けた。僕は「自分で獲得したリソースは自分で明示的に解放すべき」という考えが基本にあり、思い返すと、doGet()やdoPost()メソッド内でちゃんと自分でclose()するコーディングを長年に渡って行ってきた。flush()に関してもclose()したタイミングで行われるだろうし、初期のアホコンテナに対しては、ちゃんと後処理を行ってくれないんじゃないか、という不信感があったため、いつも自分でclose()を明示的に呼んでいた。 でも、昨日質問を受けて、果たしてclose()を自分でする必要があるのか？コンテナにclose()は任せる必要が
懐かしさたっぷりの「ファミコンの驚きべき発想力」
昨日書店に行き、「これ面白そうじゃない？」と嫁が見つけた書籍がありました。そのまま購入してさっき読み終えた、僕にとって短時間で一気に最後まで読み込めた珍しい本、それは「ファミコンの驚きべき発想力」です。 ファミコンの驚くべき発想力 －限界を突破する技術に学べ－ (PCポケットカルチャー) 現状の富豪プログラミングの真逆であるファミコンの貧弱な環境の説明から入るのですが、その貧弱さがゲームデザインにどう有利に働いていたか、がこの本の中心的なポイントとなります。価格を2万円以下に抑えながら如何に必要な機能を搭載するか、これはとても難しい問題です。 乗算除算や浮動小数点演算機能はCPUから潔く削除されていますが、これはプログラミングの工夫で十分カバーできます。グラフィックスについては、スプライトとBGというキャラクタの描画に向いている機構の提供と、グラフィックスを専門に担当するチップの存在、そし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FreeNAS8をやってみた
