HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
終わってしまうChromeアプリ
既に2ヶ月前の2016年9月8日、Google Developers Japan Blogに、僕にとって非常に興味深いブログが掲載されました。 Chrome アプリからウェブアプリへ 簡単にまとめると、「Chromeアプリは（ChromeOSを除いて）終了します」という内容でした。薄々感じ取ってはいたものの、改めて正式に言われてしまうと、とてもショックです。まあ、でも、確かに仕方のないことなんですけど、特に日本においてはChromebookを目にする機会はほとんどありませんし、そのためChromeアプリ開発者の数も非常に少なかったと思います。OpenSocialといい、Chromeアプリといい、そろそろ僕も「お前が注目した技術は数年後になくなる」とか声が聞こえてきそうですが、2年近く、かなり本気を出して取り組んできたChromeアプリの世界だけに、立ち直れるまでかなりの時間がかかったという
SyncFileSystem APIの仕様ドラフトを和訳してみました
SyncFileSystem APIの仕様ドラフトを和訳してみました Written on Feb 26, 2013. Posted in Chrome extension 時代はそろそろ「オフラインファースト」になる模様ですが、そのためにはブラウザが情報をオフラインで扱うことを可能にする機能が充実してくれないといけません。いろんなAPIを組み合わせて駆使していけば、現状でもできないことはないです。しかし、もちろん僕らは手軽にオフライン対応Webアプリを作りたいですよね？同期処理や競合など、自分で面倒見たくは誰しもないはずです。 SyncFileSystem APIはそんな僕らの要求に応えてくれるかもしれないと考えています。まだChrome Canaryでしか試せませんが、その仕様のドラフトはすでに公開されていますので、和訳してみました。 元の仕様のドラフトは、以下にあります。 SyncF
Tizen OSを動かしてみました
ひょんなことから、Tizen OSを動かしてみることになり、せっかくなのでブログに残しておきます。 インストールしたのは、以下のものたち。ホントはUbuntuで最初やったんだけど、グラフィックのチップセットが貧弱なせいかEmulatorが起動せず、それなりのスペック&ドライバがちゃんと入ってるWindows機で試してみました。 Oracle Java 7 SDK Install Manager(for Windows 32bit) tizen-sdk-2.0-windows32.exe 順にインストールしていくと、スタートメニューに「Tizen IDE」があるのがわかりますが、それはガン無視。「Tizen SDK - Emulator Manager」を選択して、エミュレータを作ってみます。x86-standardの”< “をクリックして、ほぼデフォ設定でプロファイルを作成。Display
僕が考えたChrome拡張機能を作るときのデザインパターン
最近いくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします。 Image collector extension goo.gl URL Shortener extension mixi Check button extension Semantic inspector これだけ作ってると、何となく自分でのChrome拡張機能を作り出す際のデザインパターン・・・っていう大それたものじゃないけど、ようはテンプレが確立されてきます。全く褒められない書き方をしているかもしれませんが、ここでそのテンプレ達を晒しておこうかな、と思います。 manifest.json まずはChrome拡張機能の要であるマニフェストファイルです。これは誰が書いてもさほど変わらない記述内容となるでしょう。 { "manifest_version": 2, "name":
「OpenSocial 3.0 Summit 議事録」から読み取れる流れ
2月28日に、メジャーバージョンアップとなるOpenSocial 3.0をテーマにしたサミットが行われました。その議事録が公開されています。 OpenSocial 3.0 Summit Minutes 参加者の所属企業を抜き出してみると、以下のような感じになります。ちなみに括弧内の数字は参加人数です。 Jive Software (5) Mitre (2) IBM (6) Sutro Software (1) Sugar CRM (1) EPFL (1) Office of the DoD (1) Atlassian (1) AppFusions (1) これを見ればわかる通り、すっかりエンタープライズなメンバーが揃ってます。一般的にソーシャルメディア、ソーシャルネットワーキングサービスと言われるサービスをやってる企業は一つもない。昨年の5月に行われたOpenSocial Union ev
Googleデベロッパー交流会 第５回「Open Social」に参加してきました
先週の3月14日、 Googleデベロッパー交流会 第５回「Open Social」に参加させていただいた。今回は、パネルディスカッションのパネラーの一人として、Open Socialについて他のパネラーの方々と共に語らせていただいた。 何だかんだ言って、結局僕が一番話をしちゃってたかもしれない。うーん、良かったのか、悪かったのか。。。 Open Socialというと、やはりSNSアプリケーションの開発に関する話が中心になると思っていたのだが、僕にとって非常に意外だったのは、SNSを運用している人、あるいはSNSのサーバを作っている人が会場に多く来ていたということだ。特に、地域SNSとそれらのスケールアップを課題に持っている人が多く、その解決策としてOpen Socialに期待している、という話を伺うことができた。 Open SocialでのSNSアプリのポータビリティ性を重要と考えたため
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
