Apigeeを読んでみました。全体的な感想としては、読んでよかった。これからAPIを作る際の基本的な方針になりそう。Parts」も以前読んでとても良いなと感じたのですが、こちらのほうがさらに本質的で筋肉質な印象を受けました。Apigee気になったことのメモ読みながら気になったことをメモしていたのですが、特にこれは自分のものにしたいというところを書き出していきます。Rest狂信者ではなく実践的Rest利用者のために冒頭で、Rest狂信者になることなく、実践的にRestを使う人のためのものという感じのことが書いてある。resource.例えばリソースに対して、baseとなるURLは以下の二つになるということです。関連してリソース名から動詞を排除しましょうということでした。elements.開発者はHTTPの動詞に慣れているから直感的にわかるし、いろんなことができるからHTTPの動詞で処理は決める。/owners/5678/dogsこんな感じのインターフェイスにすると複雑性が増す。/resource/identifier/resource以上に深くはしない。/dogs?color=red&state=running&location=parkオプショナルな状態や属性をベースURLの?以降につけることで、シンプルに使えるようにする。codesを使いましょう。その代わり、errorにいろいろな情報を含めてあげましょう。errorが関連するドキュメントのURLを一緒に返してあげるのは良い方法。codesを返すのは普通かなと思っていたら、Facebookの場合は常に200を返して、responseのbodyでハンドルする仕組みになっているらしい...(今もそうかは知らないけれど)。numberをmetadataとして含める。limitとoffsetのところ、良いと思うけど、timestampで要求するのもいいような気がする。Twitterはそれだった気がする。resources?リソースに関係ないresponseはどうする?verbsにしたりするらしい。names?JavaScriptの慣習に従うと良いらし。modelがいいらしい。APIsこれ、嫌な奴。一つの目的を達成したい(例えば、たぶん、shopの一覧と言い値をしているかどうかが欲しい)ときに、shopごとのいいね情報を個別でrequestしなきゃいけない時とかだと思う。これには明確な解決法が示されている。これがとくに実践的Restぽい。先にショートカットを作ってはいけない。コメントデータの処理方法の詳細はこちらをご覧ください。