Stu Charlon氏は、WWW 2011で"the Write Side of the Web"と名付けられたRESTfulデザインのワークショップのスライドを提示した。"読み込み側"がすでに成功しているとしたら、情報をWebに"書き込む"のは、RESTの誇大広告の中で、もともと、主張していたように簡単ではない。書き込み側には、クライアントとサーバー間のセマンティクスとエラーハンドリングである、カップリングとして知られる、適切な契約が必要になる。
読み込み側 書き込み側
- GET
- RDFa/マイクロフォーマット
- ブラウジング
- Atom & RSSフィード
- 検索
- セマンティックWeb
- POST
- AtomPub
- Integration
- Facebookステータス
- メディア共有
- e-Commerce
Stu氏は、APIの呼び出しとシステム統合を進めて、集中管理を進めることにより、よりよい書き込み側の需要が高まると説明する。書き込み側を処理する一般的な方法が存在しないため、RESTful設計と呼ばれる多くが分散してしまっている。
RESTは、CRUD (Create, Read, Update, Delete)ではなく、HTTPでもありません。Postは、'create'と直接結びついておらず、CRUD自身はスケールで、複雑性に通じます。
CRUDでは、契約以外にもバリデーションルールと例外ハンドリングが必要になるが、状態が変更されるときにはとりわけそうである。このケースでは、クライアントはサーバーサイドのステートマシンを少なくても部分的には理解している必要がある。彼のプレゼンテーションによるとStu氏は、クライアントが「情報空間でエージェントとして動作する」ハイパーメディアベースのプログラミングモデルについて解説する。彼の提案するクライアントは、以下のようにあるべきである。
ゴールの方向性
リアクティブ
ハイパーメディアワークスペースを持つ
「効果(effects)を補足する」能力
みんな「書き込み側」を見つけ始めたところで、それまでのほとんどのAPIがRESTfulの方法で設計されているかどうかを誰も気にしていなかった。RESTfulieには、Stu氏の提案につながるサーバーのおもしろいコンセプトを提案している。しかし、クライントとサーバー間の契約では、RESTコミュニティによる様々な見落とされた問題が残っている。
あなたは「書き込み側」向けにAPIを設計しているだろうか？これについてどのように考えるだろうか？