HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
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
僕が考えたRuby on RailsとDojo toolkitで作るWebアプリのデザインパターン
今年の前半、ある限定した範囲で使うツールを以下の構成で作ってました。 Ruby 1.9.3 Rails 3.2 Dojo toolkit 1.7 Railsで何かを作るのが久々だったこと、 Erlangで最初作ったものをRubyベースでPortingすること、という背景があったのですが、実際に僕がRubyベースで書き直したときの書き方が結構満足いくものだったので、それをここで紹介してみたいと思います。もちろん、ドメインモデルへの考え方、RESTfulなWebアプリケーションの作り方、MVCモデルの適用、などなど「Railsならこうするだろ」というものがありますが、 「 広く一般に言われているセオリーは一切気にせず自分が作りやすい組み方をする」 という至極自己中心的な考えを持って確立されたのが以下に説明することになります。 すっごく違和感を持つ人も多いと思いますが、「こんな作り方もできるんだ
「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 Developer Day 2011 Tokyoで僕的に印象に残った名言
今年のGoogle Developer Dayも昨日無事に終わり、今日現実に戻るのがかなりしんどかったです。忘れないうちに、印象に残った 迷名言を、感謝の意味も込めてここに書きのこしておきます。 ”なにごともエンジニアありき” グーグル 徳生健太郎さん Keynoteにて。 そうですよね！やっぱりそうですよね！と思わず ツイートせざるを得なかった名言です。 ”今日はデモしないけど動きます。僕を信じてください。” グーグル @tmatsuoさん Keynoteにて。 まさかの名言。信じるしかありません。 ”Change the world” グーグル Julia Ferraioliさん Google+ APIに関するセッションにて。 世界は変えられます。Juliaはそれを信じてるだろうし、僕も信じてます。 ”僕もつい最近までいろんなサイトで同じパスワード使ってました。反省してます。” グーグ
OAuth2.0によるGoogle+ APIのアクセス方法
Google+のAPIが先日公開されました。API Keyを使ってシンプルにAPIアクセスを試すことができるのですが、本来であればOAuth2.0にてアクセストークンを取得しAPIアクセスする方式でなければ今後公開されるであろうAPI群は利用できないはずですので、ここでOAuth2.0によるGoogle+ APIのアクセス手順を紹介しておきましょう。全手順において、プログラミングをすることなく試すことができます。 Client IDの発行 まずはClient IDやClient secretなどを発行しましょう。まずは、Google APIs ConsoleにWebブラウザでアクセスします。 https://code.google.com/apis/console/ まだプロジェクトを作成していないのであれば、Other projects→Create…にて新規にプロジェクト作成を行います
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
