APIのURL設計をしようと思い、その前に有名サービスのAPIのURL設計がどうなっているのかについて調べました。 一覧を載せた後に、「多数派なURL設計」を書きたいと思います。
t_wada さんの議論のポイント http://www.slideshare.net/t_wada/restful-web-design-review より。 やりたいこと vs. (Rails的な)作りやすさ 確認画面、プレビュー画面、完了画面… リソースの移動、コピー トランザクションの表現 複数レコードを選択して更新する UI 207 Multi-Status の誘惑 URLに機械採番の id が含まれる セキュアじゃ無い 永続的でない(かも) APIのバージョニング 自前でやっていた https://github.com/bploetz/versionist 良さそう rails4 の PATCH メソッドどうよ? あまり非同期処理に頼らない DOM Scripting の原則に従う RESTfulなサーバとリッチjsという設計に倒しすぎるとUXや保守性が低下する可能性があるので
いつも思いつきで恐縮ですが、「Webアプリの画面はRESTfulなAPIの一クライアントにすぎない」んじゃないかと考え始めています。 ひらめいたのは、Rails2.0のルーティングを調べていたとき。scaffoldを使うと、下記のようなルーティングになるらしい。 アクション メソッド URL例 一覧画面 GET /bookmarks 登録画面 GET /bookmarks/new 登録処理 POST /bookmarks 参照画面 GET /bookmarks/1 編集画面 GET /bookmarks/1/edit 更新処理 PUT /bookmarks/1 削除処理 DELETE /bookmarks/1 このうち、登録画面と編集画面に違和感を覚え、はたと気づきました。一覧画面や参照画面がリソースの素直な表現であるのに対し、登録画面と編集画面はPOSTやPUTのためにやむなく用意された
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く