WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめAPIのURL設計をしようと思い、その前に有名サービスのAPIのURL設計がどうなっているのかについて調べました。 一覧を載せた後に、「多数派なURL設計」を書きたいと思います。
8/20 RESTful勉強会 の議論ネタと予習 - Qiita
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の一クライアントにすぎない？ - 岩本隆史の日記帳（アーカイブ）
いつも思いつきで恐縮ですが、「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のためにやむなく用意された
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jamie On Software - Journal - RESTful CodeIgniter Routes
RESTful API Design, Second Edition
