Ресурс Angular — структура модели по умолчанию

пытаясь дать простой ответ - для простых структур я бы использовал что-то вроде

module.factory('Item', function($resource) {
  var resource = $resource('http://xmpl.io/items/:itemId', { itemId: '@id' },
    // you can also define transformRequest here: 
    { transformRequest: function(data) {
      // data can be transformed here
      return angular.toJson(data);
    }});

  return angular.extend(resource.prototype, 
    {
       name: null,
       categories: []
    });
  });

но затем помните о необходимости "выравнивать" объект.

а для более сложной модели я бы выбрал restangular

аналогичная тема также обсуждается здесь: Как я могу расширить конструктор ресурса AngularJS ($resource)?

Я бы пошел дальше и в первую очередь пересмотрел структуру моей модели в бэкэнде - модели на стороне клиента должны просто следовать уже определенным, а не переопределяться в блоке преобразования. Итак, чтобы ответить на ваш вопрос, структура модели «по умолчанию» исходит от сервера. То, что вы получаете в своих объектах $resource, имеет структуру того, что возвращает ваш сервер.

Для начала, действительно ли можно вызывать $save для модели Item, когда пользователь заполнил некоторые значения? Очевидно, что мы хотим сохранить списки, связанные с элементом, а не сам элемент. Отдельный ресурс, определенный в бэкенде, скажем, items/<item_id>/list, может быть более чистым решением. Это может не очень хорошо масштабироваться, так как вам придется делать отдельный GET запрос для каждого элемента, чтобы получить его список, но это правильный способ RESTful сделать это.

Распространяя этот подход на пример в вашей скрипке, я думаю, что схема маршрутизации, такая как buildings/<building_id>/floors/<floor_id>/units/<unit_id>, была бы правильным решением. Отправив GET запрос buildings/, вы получите список зданий; каждое здание в возвращаемом массиве должно быть экземпляром модели Building, для которой задан правильный URL-адрес, чтобы пользователь мог выполнить одно POST и обновить только имя здания, вместо отправки всей структуры обратно на сервер. Применение этого рекурсивно к вложенным ресурсам должно дать вам чистый и лаконичный способ работы с изменениями модели.

Что касается части пользовательского интерфейса, я бы определил три директивы для зданий, этажей и юнитов, и пусть каждая из них управляет массивом с соответствующими ресурсами, а также позаботится о привязках пользовательского интерфейса к значениям модели.

Так как же может выглядеть модель Building?

var BuildingResource = $resource('/buildings/:id', { id: '@id' });

Вызов BuildingResource.query() должен дать массив существующих зданий. Добавление нового здания может выглядеть так:

var newBuilding = new BuildingResource();
newBuilding.$save().then(function(building) {
  $scope.buildings.push(building);
}, function(errData) {
  //Handle error here...
});

Этот шаблон должно быть легко распространить на остальные ресурсы — обратите внимание, что сервер должен возвращать для каждого здания только name и id; зная id, достаточно создать URL (и объект $resource соответственно) для получения необходимых дочерних ресурсов (в данном случае этажей).