

例えばUserモデルとProductモデルがあったとして、  
それぞれがuser has_many products, product belongs_to userの関係の時に、  
自分はウェブアプリだとURLを短くしたいので/users/:user_id/productsというURL構造にして:user_idのパラメーターからユーザ情報を取得するのではなく、  
userの情報はcookieに噛ませて/productsのみのURLという風に普段は設計しています。

ただ今回grapeというgemを利用してiOS向けにAPIをつくろうとした所、cookie経由でユーザー情報を取得する事は適していない用に感じ、APIの方のURL構造を変更しようかなと考えました。

そこでお聞きしたいのが、そもそも自分のWebアプリとしてのrailsのURL構造が悪いのか、APIのURL構造はこの用に設計しなければならないものなのかという事です。今回初めて本格的にiOS向けAPIを開発しているもので、、、。  
ぜひとも宜しくお願い致します。


CC BY-SA 3.0
2015-04-29T09:28:11.227
9664
2015-05-31T02:34:30.340
9539
question
ios ruby-on-rails api grape url-routing
Webアプリとしてのrailsのroute構造とiOSアプリのAPIとしてのrailsのroute構造は別でもいいのでしょうか？


API の場合、OAuth などでユーザを認証してToken を発行してから、そのToken
をアクセスのたびにヘッダーに埋め込んでセッションを管理することが多いです。

だから、Cookie なのかToken なのか違いはありますが、基本は一緒です。Token からcurrent_user
を特定して、`/user/:user_id`を省略することは普通に行われます。


CC BY-SA 3.0
2015-04-30T14:32:09.000
9708
2015-04-30T14:32:09.000
9508
9664
answer


原則論でいば、`/users/:user_id/products`というURLではなく`user`の情報はcookieに持たせてそれをもとに`/products`の返す内容が変わるというのは状態(=state)に依存したアプリケーションになっており、ステートレスであることを求めるRESTの原則に反していることになります。結果として、ステートレスなクライアントでは`user`が特定できないという事態になっています。

cookieに保存されたuserの情報というのが認証情報で、/productsでは「認証されたユーザー(=自分)」に紐付いたリソースのみを扱えばよい、さらに、認証されたユーザー以外(=他人)の`product`を扱う必要がない、ということであれば、APIでも認証情報からユーザーを特定すれば良いでしょう。

cookieに保存されているのが認証情報ではない場合、たとえば、`/user/foo`を表示したら`foo`をcookieに保存しておき、`/products`ではその情報を使って処理をしている、というのであれば、設計がまずいといえますので、`/users/:user_id/products`というURL構造に改めた方が良いでしょう。


CC BY-SA 3.0
2015-05-01T01:34:03.873
9721
2015-05-01T01:34:03.873
5793
9664
answer