Как структурировать связанные URL RESTful

Question

У меня есть два ресурса, buildings и rooms.

Логическим API URL будет:

/api/buildings   -> all buildings 
/api/buildings/1   -> building #1 
/api/buildings/1/rooms -> rooms from building #1 
/api/buildings/1/rooms/5 -> room #5 from building #1 
/api/rooms    -> all rooms, any building 
/api/rooms/5    -> room #5/(?) Is this necessary? 

Как структурировать глубокие узлы? Похоже, что есть 3 способа получить те же данные, когда мы вводим 3-й слой

#1) /api/buildings/1/rooms/5/chairs/3 

#2) /api/rooms/5/chairs/3 

#3) /api/chairs/3 

Похоже, что существуют различные способы, чтобы получить стул # 3, что означало бы дублировать работу.

Answer 1

Не имеет смысла иметь /api/buildings/1/rooms/5/chairs/3 или /api/rooms/5/chairs/3. Ресурсы api/.../chairs должны иметь ссылку на /api/chairs/3, а ресурс /api/buildings/1/rooms должен содержать ссылку на /api/rooms/5/.

Answer 2

Я предлагаю попытаться избежать гнездования, где это возможно.

/api/buildings 
/api/buildings/1 
/api/buildings/1/rooms 
    # GET returns all rooms in building 1. Each room has a "self" link 
    # which points to /rooms/{id}, and a "building" link which points to 
    # /api/buildings/1 
    # POST adds a room to the building and the rooms collection 
    # DELETE deletes the room from the building and the rooms collection 
    # This is reasonable because a room's scope is the building it belongs to 

/api/rooms 
    # No POST supported 
    # DELETE deletes the room from its building and this collection 
/api/rooms/5 
/api/rooms/5/chairs 
    # All chairs currently in this room 
    # POST moves an existing chair to this room 
    # DELETE removes an existing chair from the room, but not /chairs 

/api/chairs 
    # POST creates a chair 
    # DELETE deletes the chair and removes it from the room it belongs to 

Возможная проблема заключается в том, что POST действует по-разному в /buildings/1/rooms и /rooms/5/chairs. Вам решать, подходит ли это несоответствие или нет. Альтернативы:

• позволяют/заставить пользователя создать комнату с помощью POST/номеров, а затем в качестве отдельной транзакции назначить его в здание через POST/здания/5/комнаты
• делают здание помещение принадлежит к требуемой части его конструкции, когда POSTing/номера
• использует параметр запроса, например POST /rooms?building=12 { body }. Эта конструкция является нетипичной и не рекомендуется.