RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
次世代Webアーキテクチャーの話 (CROSS2014を聞いて)
CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 （ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ
RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
【クラウドコンピューティング】 格安ストレージサービスを活用する
クラウドは本当に安いのか！？ Azureの登場もあって下図のようなクラウド比較情報が充実してきた。 Windows Azureの料金はGAEやEC2より安いのか （昨日、AWSの値下げがあった） クラウドのコストを考える際に重要だと思うポイントは、CPUコストとストレージコストの２つを分けて考えるということ。CPUコストは、できれば、ココで示したような、TPC-Cを元にしたPrice/Performanceといった値で比較するとよいと思うのだが、Publicクラウドについては各社とても安いので、単純にCPU利用料で比較してもいいのかもしれない。ただ、Amazon EC2のc1.xlargeといったハイエンドサーバを長時間使うと割高になるので、必要なときに必要なだけ利用するといったように、短時間に効率よく利用する工夫は必要になると思う。 問題はストレージコストの方だ。ココで指摘されているよう
【Google App Engine】 Keyとカウンタは別々に考えるといいかも
この記事書いているあいだにこんなニュースを見つけた。これはすごいや。 100万PV／日のmixiモバイルアプリをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー さて、本題 不可能と思い込んでいたことができることもある 何度かイタい目に遭うことで、またどうせ出来ないだろうと思い込んでしまうことを学習性無力感という。長期間にわたって鎖に繋がれたままの犬は、鎖を外してもしばらくは逃げないそうである。GAEはもともと情報が少ないのと、嵌りどころ満載なこともあって、学習性無力感に陥ることがしばしばある。だから、一人悶々とやるより、Blogに晒したり、GAE Nightなどの集まりに出向くなどして、情報共有に努めるのがよろしいかと思う。そこで重要なのは、ありのままの事実を晒すということ。現時点で正しい答えを識っているものは皆無に等しいのだから、誰かに正しい答え
【クラウドコンピューティング】 Scaleするかどうか、それが問題だ
エンドユーザにとってクラウドデータベースで嬉しいことは何もない？ クラウド時代のデータベースという記事には、「戯れ言を垂れ流してみます」といいつつ、本質的なことが書かれている。 key-value型のインスタンス群に対して集合操作ってのは、例えばJoSQLみたいなのもあって、いやいやそもそもデータ量がねって話に対して、でもGAEってクォータきつくないっけ？（これもよく分かってないんですけど、調査不足で書いちゃって申し訳ないです）ってことを考えると、 BigTableが使えるって言ってもほんとの意味で大量データをブン回せるわけでもないのかな、とか、いやそもそも集合操作無用でござるっていうなら、 HTMLのフォームをPOSTされたらそのままテキストファイルとして保存しちゃってLucene頑張れってほうが良くね？ とか、そもそも何だよその「明細」ってスキーマ（クラスでもテーブルでもエンティティで
【Google App Engine】 疎結合とバージョニングについて
ぶいてく流スケーラブル設計３大要素 私たちがスケーラブルなアプリを作る際に重要だと考えている要素は、疎結合、バージョニング、非同期の３つである。 今回は、疎結合、特にバージョニングについて詳しく述べる。非同期（TaskQueue）は次回の予定。 疎結合 GAEといったスケーラブルなプラットフォームを利用することで、単純なWebアプリでもスケーラビリティを得られるわけだが、さらにそれをRESTfulなWebサービスにすることで、より柔軟なスケーラビリティを享受できる。マッシュアップアプリがいい例で、ワンソース・マルチビューを実現できる。それは、この記事や、実装例で示してきたとおりである。これらはReflexやReflexGaeフレームワークにより、EntityからJSONやXML等に変換することで実現している。 バージョニング この記事の最後の一文は、なんのこっちゃ！？と思った方も多いと思う
【雑記】 そろそろMVCモデルについて一言いっておくか
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
