HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
OAuthがソーシャルログインで使われるようになった経緯
最近の僕の趣味は、stack overflowに来た質問に回答を付ける、ということです。特に本家英語版の方では、英語の読み取りと作文の練習をかねてやってます。もちろん、日本語版の方でも、回答できそうな質問が来たら、積極的に回答するようにしています。たまに間違えた回答付けてしまって-1をもらうこともありますが、それを含めての貢献かな、と。気にしない気にしない。 さて、日本語版の方でOAuthに関する以下の質問が来ていました。 OAuthはどのようにしてソーシャルログインとして使用されるようになったのでしょうか？ 下記の記事をみるとOAuthはもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。 本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史）でソーシ
【翻訳】JSON Web Tokenライブラリの危機的な脆弱性
【翻訳】JSON Web Tokenライブラリの危機的な脆弱性 Written on Sep 14, 2015. Posted in Web Technologies 以下の内容は、JSON Web Tokenを扱うライブラリの脆弱性に関する報告内容を和訳したものです。 https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ JSON Web Tokenライブラリの危機的な脆弱性 最近、いくつかのJSON Web Token実装のセキュリティについてレビューしていた間に、私は検証処理をバイパスする攻撃が可能な危機的な脆弱性を持つ多くのライブラリを発見しました。多くの実装や言語を横断して、同じ2つの欠陥が見つかりました。そして、問題が起こる場所を書き上げることが助けになると
Javaのgetter,setterメソッドは（特に）GUI部品のための規格だった話
こんな記事があった。 「 getter/setterとはなんだったのか」- プログラマーの脳みそ JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。 それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」で
Web IntentsとSchema.orgの連携が模索され始めています
Web IntentsとSchema.orgの連携が模索され始めています Written on Jul 13, 2012. Posted in Web IntentsSemantic Web Web Intentsは、Webアプリケーション間の連携を可能とする技術となりますが、そこで規定されていることの中心は「ユーザが何をしたいか」についてです。つまり「共有したい」「編集したい」「保存したい」といった行為に関することであり、「何を」という部分については、そのペイロードの部分の規定はあれど、厳密な説明は仕様に書かれていません。それは当たり前であり、Web Intentsの守備範囲外ということになりますが、では「何を」の部分が実際にどのように規定されるかについて、Schema.orgがその答えになるのではないか、という記事が semanticweb.comに投稿されていましたので、翻訳してみま
プロジェクト作成時の自動ビルダー設定ムズっ！
最近はあちこちで「プロジェクトでEclipse作ってるよ」という話を聞くようになった。汎用的なプラグインではなく，あくまで特定のプロジェクトの開発で使えるものを作っていることが多いようだ。つまり，潜在的なプラグイン開発者は着々と増えつつあるということだ。「 Eclipseプラグイン開発」ブログのアクセス数も着々である。 知り合いのNetPenguinクンも，悩めるプラグイン開発者になっているようだ。 Eclipseプラグイン開発３日目 Java プロジェクトや Tomcat プロジェクトなどの JDT のネイチャーが絡むプロジェクトを新規に作成した場合に、Java ビルダーだけでなく自作のビルダーをプロジェクトに自動的に追加するということをしたいのですが、JDT のビルダーやネイチャーが持つ拡張ポイントにはそのようなことを可能にするものは無いようです・・・orz Eclipse自体は柔軟性
DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。 結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。 DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
