32326
表題のように、複数のモデルをまたがる場合のRestなAPI設計で迷っています。

例えば、このStackOverFlowをスマフォアプリ版を出すとします。  
またサーバがApiを提供することとします。

この時、トップページをクライアントで表示したいとします。  
すると必要なデータは、自身のUserデータ、Questionとそれに結びつくTag、求人広告、受信箱、実績、他の質問に結ぶつく他のユーザデータ。  
パッと思いつく限りだと、これぐらいの情報がトップを表示する際に必要そうな気がします。

これらのリソースをRestに従って一つずつとっていってもいいのですが、リクエスト数が増えサーバの負荷があがると思われます。  
そうなるとApi設計として、「top/」のようなURL形式でトップ画面に必要な情報を一気に持ってきて欲しいというような、要望が出ると思います。

そしてこの例は特殊なケースではなく、例えばアプリの起動時や、質問を見る時もこのように複数のモデルにまたがった情報を一気に取得したいという要望がある気がします。

こうなると少なくとも情報の取得する場合は、Restで一つ一つのリソースにアクセスするのはむしろ補助的な立ち位置となり、「init/」「top/」「question_info/」のような場合に応じたApiがメインになるような気がします。

こだわる必要性はないとは思うのですが、Rest的な思考からは外れていくように思います。  
そもそもアプリ系ではRest的なApiは向いていないのでしょうか？または、何か設計が間違っているのでしょうか？  
ご回答いただければ助かります。
CC BY-SA 3.0
2017-02-02T01:59:57.683
32316
2017-02-02T05:31:32.207
20353
question
rest url
複数のモデルをまたがるRestなAPI設計
メインのリソースをURLのパスで指定し、クエリパラメータで追加のリソースを要求するというやりかたがあります。

例えば質問を取得するのに、`GET /questions/32316`というリクエストで

```

    {
      "title": "複数のモデルをまたがるRestなAPI設計",
      "description": "表題のように、複数のモデルをまたがる場合のRestなAPI設計で迷っています。",
      "votes": 1,
      "tags": ["rest", "url"],
      "user": 20353
    }
    
```

というのが返ってくるAPIがあって、またユーザを取得するときは`GET /users/20353`というリクエストで

```

    {
      "name": "お寿司",
      "reputation": 8
    }
    
```

というのが返ってくるAPIがあるとして、質問ページを表示する際には、上記二つのAPIをたたくのではなく、`GET
/questions/32316?embed=user`というリクエストで

```

    {
      "title": "複数のモデルをまたがるRestなAPI設計",
      "description": "表題のように、複数のモデルをまたがる場合のRestなAPI設計で迷っています。",
      "votes": 1,
      "tags": ["rest", "url"],
      "user": {
        "name": "お寿司",
        "reputation": 8
      }
    }
    
```

を返すようにするという感じです。  
サーバ側の処理はちょっと複雑になるでしょうが、RESTな感じを保つことはできます。  
([参考](http://qiita.com/mserizawa/items/b833e407d89abd21ee72#%E9%96%A2%E9%80%A3%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E5%9F%8B%E3%82%81%E8%BE%BC%E3%82%80%E6%89%8B%E6%AE%B5%E3%82%92%E4%BD%9C%E3%82%8D%E3%81%86))
CC BY-SA 3.0
2017-02-02T05:31:32.207
32326
2017-02-02T05:31:32.207
19437
32316
answer