The importance of being versioned - Human Who Codes
Posted at February 22, 2011 by Nicholas C. Zakas Tags: API, Versioning, Web Services If you write or use a public web service, please read this post carefully. I’m shocked and saddened at just how poorly many of these APIs are designed. I’m not necessarily talking about the choice of REST or not, or XML vs. JSON, as these are somewhat matters of preference and usage patterns. I’m talking about whe
JavaScript APIやWebサービスAPIはバージョン化が必要 - 開発者指摘
Nicholas C. Zakas is a web software engineer who specializes in user interface design and implementation for web applications using JavaScript, Dynamic HTML, CSS, XML, and XSLT. Yahoo!の技術者でありJavaScript関連の技術紹介に定評のあるNicholas C. Zakas氏がNCZOnlineにおいて、パブリックに公開されているWebサービスはバージョン管理されたAPIを提供すべきだといった内容の記事を公開した。依然として多くのWebサービスがバージョン管理されていない状況で提供されており、開発において不利益を被っているという内容になっている。 デスクトップやサーバの開発で利用されるライブラリはバージョ
ブログ新開設！ | yusuke.blog
久しぶりに新しいブログを建てました。「侍ズム」(http://samuraism.jp/diary)ではPebbleというPure Javaのブログシステムをベースに改造を加えて使っていました。オリジナルのPebbleの開発は止まり、システムが老朽化し、イマドキのWordPress等のCMSと比べるとさすがに使い勝手が悪くなってきて書く気が起きなくなってしまっていました。ドメインも新たに、WordPressで心機一転！旧サイトのコンテンツは追い追い移行してリダイレクトします。こちらのブログのタイトルは未定。会社名(株式会社サムライズム)とブログ名(侍ズム)が混同されることがあるので、何か新しい名前にする予定。
RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Yogaを使ってRESTを柔軟にする
ここではこのYogaの使い方をデモし、RESTシンタックスの使いやすさを保持しながら、Yogaがアプリケーションの性能を改善することを示します。 リソースのフィールドを定義する 次は典型的なRESTリクエストで、リソースのインスタンスを検索しています。これはUserリソースタイプに関連するすべてのフィールドを返します。 GET /user/1.json セキュリティや性能を考慮してあるユーザの名前とロケーションデータだけを取得するリクエストを生成したい場合はどうすればいいでしょう。この場合は、リクエストにセレクタを追加できます。 GET /user/1.json?selector=(id,name,city,state,country) 公開APIを公開するためには無制限にセレクトできる機能をエンドユーザに与えたくないかもしれません。これは、定義されたセレクタにエイリアスを付加することで達
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
InfoQ: RESTfulなアプリケーションを記述する
しかしながら、上述のRoy Fieldingの言葉を言い換えると、このようなアプローチはRESTの基本的な原則の一部と相反します。たとえ私たちがこの異議を無視するとしても、 HTTP上に分散型アプリケーションをRESTfullに構築しようとしている人たちには、根本的な問題が残ります。契約を形式的に定義することなくサーバーからの取得はどうするのでしょうか？契約なしでクライアントとサーバーが正しく実装しているということをどのように確かめるのか、それぞれの設計仕様書だけでなく、その他、適切なビジネス/技術ポリシーはどうするのでしょうか？ アプリケーションプロトコルとしてHTTPを使用し、RESTfullな構築をしている分散型アプリケーションには、同じような性質と種類の契約があります。私たちは、何を探し、どこを探すかを知る必要があります。同じ方向にしたがい、私たちが記述言語に向かうならば、それはW
不思議な円グラフを描くウェブサービス作ったよ - aike’s blog
最近ツイッター界隈で不思議な円グラフを見かけました。 こんなやつです。 ちょっと調べてみると昨年の報道番組からキャプチャした映像のようです。 このグラフを見て、その手があったか！という新鮮な驚きを感じました。これまでの円グラフの常識にとらわれず、円の中心からあえてずらした位置から分割することで飛躍的に表現の幅を向上させています。無味乾燥で機械的なグラフにくらべて製作者の強い思いがぐっと伝わってきます。なんとイノベーティブでなんとワンダーなグラフなのでしょう。 でも、このグラフ、実際に描こうと思うとけっこう面倒です。Excelのグラフ機能をみても中心点の位置をずらす方法はなさそうです。 そんなわけでゆがんだ円グラフを描くウェブサービスを作りました。 ワンダー・グラフ・ジェネレイター 項目の追加変更はもちろん、中心をずらしたり、楕円形にして項目を強調したりできます。円グラフの秘められた表現力を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PyCon Taiwan 2013レポート ～イベント前日
REST APIの良い、悪い、醜い
SOAP から REST へ - その方法と意義
Sentry at Disqus