HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
2016年度版 僕が考えたChrome拡張機能を作るときのデザインパターン
4年近く前の2012年に 僕が考えたChrome拡張機能を作るときのデザインパターン というエントリを書きました。最近参加したイベントで「よういちろうさんの拡張機能の記事見て作ってみました〜」と声をかけてくれた人がいて嬉しかったのですが、2012年のそのエントリは、すでに内容が古くなってしまっています。最近の状況を踏まえて、内容を新しくした「2016年度版」を書いてみようと思います。 変更しようと思った点は、以下です。 prototype.jsは使わず、ECMAScript 2015で書く。 Background Page(常駐型)ではなく、Event Page(非常駐型)にする。 そもそも最初のコードセットは自分で書かない。 本文やコード的には、2012年度版をコピペしています。 前にいくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします
オレ流AngularJSを使った設計ポリシー
Chrome MySQL Adminでは、 AngularJSを使って実装を行っています。Chrome appsでは、 何らかのMVC Frameworkの利用が勧められています。 AngularJSは、Controller、Directive、Template、Serviceなど、いくつかの部品群を組み合わせてアプリケーションを構成することになります。その機能の豊富さ故に、実はちゃんとしたポリシーを決めておかないと、いかようにでも作れてしまうために、かえって複雑さが増してしまうという危険性も出てきます。もちろんアプリケーションの作り始めは試行錯誤の連続なのですが、徐々に自分なりのポリシーみたいなものが確立されてくるはずです。 本エントリでは、Chrome MySQL Adminでの設計/実装ポリシーを簡単に紹介してみたいと思います。ちなみに、全てのソースコードは、以下にあります。 htt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
