HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Javaのgetter,setterメソッドは（特に）GUI部品のための規格だった話
こんな記事があった。 「 getter/setterとはなんだったのか」- プログラマーの脳みそ JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。 それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」で
SyncFileSystem APIの仕様ドラフトを和訳してみました
SyncFileSystem APIの仕様ドラフトを和訳してみました Written on Feb 26, 2013. Posted in Chrome extension 時代はそろそろ「オフラインファースト」になる模様ですが、そのためにはブラウザが情報をオフラインで扱うことを可能にする機能が充実してくれないといけません。いろんなAPIを組み合わせて駆使していけば、現状でもできないことはないです。しかし、もちろん僕らは手軽にオフライン対応Webアプリを作りたいですよね？同期処理や競合など、自分で面倒見たくは誰しもないはずです。 SyncFileSystem APIはそんな僕らの要求に応えてくれるかもしれないと考えています。まだChrome Canaryでしか試せませんが、その仕様のドラフトはすでに公開されていますので、和訳してみました。 元の仕様のドラフトは、以下にあります。 SyncF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
