ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
By: Silk Engineering BlogJune 30th 2014We are excited to officially announce the open source release of our REST framework rest! rest is a set of packages used to write, document, and use RESTful applications. You write your API in Haskell using rest’s DSL. This API can then be run in different web frameworks like happstack, snap, or wai. Additionally, you can automatically generate documentation
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
winplusさんが、色々と有意義な考察をなさっています。 http://d.hatena.ne.jp/winplus/20120716/1342407196 ： 「アプリケーション状態エンジンとしてのハイパーメディア」というのは、アプリケーション状態はすべてリソース(≠<リソース>)として存在しているため、リンクをつうじてリソース間を移動することがそのままアプリケーション状態の遷移となる、ということだと理解しています。 ここで、「リソース」と「<リソース>」が区別されていますが、「リソース」に関しては、次の説明で十分だと思います。 リソースにはぜんぶURLをつける。つまりURLでリソースを識別できるようにする。 このような解釈に対して疑問に思うことがあります。この疑問が解決すれば、「<リソース>」から「リソース」に乗り換えてもいいと思っています。 [追記]「人間はどこにいる？」という見出
This document provides guidance on designing RESTful APIs. It recommends using nouns instead of verbs, keeping URLs simple with only two endpoints per resource, and following conventions from leading APIs. Complex variations and optional parameters should be "swept behind the '?'." The document emphasizes designing for application developers by making APIs intuitive, consistent and complete while
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
When designing your first REST system there are a variety of mistakes people often make. I want to summarize them so that you can avoid them. If any are unclear, ask for more information on rest-discuss. Using HTTP is not enough. You can use HTTP in a Web service without SOAP or XML-RPC and still do the logical equivalent of SOAP or XML-RPC. If you're going to use HTTP wrong you would actually be
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
圏外からのWeb未来観測、2回目のゲストは『Webを支える技術』（注1）の著者の山本陽平さんです。山本さんは、クールでロジカルな話し方をする人で、一見、典型的な理系の技術者という印象なのですが、実は、すごく激しいパッションを秘めた人でした。技術的に正しい選択を通すためには会社を辞める覚悟までしていたそうです。現代に生きる侍の一人ではないかと思います。 『Webを支える技術』に入れなかったもの 中島：『Webを支える技術』は、もう定番の教科書としての評価が定まってますね。 山本：essaさんにもレビューしていただいて（【1】、【2】）ありがとうございます。 中島：何よりこの本は、話題の絞り込みが適切だと思うのですが、意識してカットしたところとかはあるのでしょうか？ 山本：まず、プログラミング言語に依存したくなかったので、具体的な言語のコードはほとんど入っていません。その代わりHTTPの生々
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
Web開発フレームワーク「Ruby on Rails」の待望のバージョン2がリリースされた。 バージョン2がリリースされたのは12月7日。主要な強化機能としては、REST（Representational State Transfer）のサポート強化と、セキュリティの改善などが挙げられる。 「Rails 2.0で気に入っているのは、RESTfulの原則を追求してアプリケーション開発が調和的になった点だ」とRuby on Rails作成者デビッド・ハイネマイヤー・ハンソン氏はeWEEKに語った。「これにより、アプリケーション開発が予測可能で、クリーンで、楽しめるものに感じられる。HTTPは常にそれを正しくやっていた。われわれWebアプリケーション開発者がそれを理解し、評価するのに少し時間がかかった」 ハンソン氏は、米シカゴのWeb製品開発会社37signalsの開発者。同氏はRails 2.
2006年10月20日13:15 カテゴリBlogosphere doc#fragment と doc のブクマが違うってのはどうよ? というハテナオヤにrequest。 naoyaのはてなダイアリー - はてなブックマークの裏側その後 となってますが、現在 10 月の方はというと ユーザー: 60,000人 ブックマーク数 787万件 サーバー: 30台 といった構成になってます。 http://www.example.com/path/to/documentとhttp://www.example.com/path/to/document#fragmentが違うブクマとなる仕様ってなんとかならんのか。 よくあるのは、ある記事をブクマしようとして、 http://blog.livedoor.jp/dankogai/archives/50657238.html にブクマしようとして、 htt
ITコンサルタントのジェシー・ジェームズ・ガレット氏は10月3日、米カリフォルニア州サンタクララで開催中のイベント「AJAXWorld Conference & Expo 2006」（10月2日〜4日）の基調講演で、Webアプリケーション開発技術である「Ajax（Asynchronous JavaScript + XML）」は、適切に使用しないと危険な目に遭うと警告した。同氏は『Ajax』の名付け親とされている。 米アダプティブ・パスの設立パートナーで、同社のユーザー・エクスペリエンス戦略担当ディレクターを務めるガレット氏は、Web上で非同期の相互作業が可能になるといったAjaxの主な利点を強調したうえで、すべてのケースに適用できるわけではないと指摘し、Ajaxを乱用するリスクを、ローラースケートで走り回る行為にたとえた。 同氏は、多くの人々が、Web上でよりダイナミックなコンテンツのナビ
Jersey、AJAX、JSONを使ってRESTに挑戦しよう ... REST（Representational State Transfer）は、HTTPを介した包括的な方法でデータを扱う強力で軽量なアーキテクチャです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く