RESTful Много-ко-многим возможно?

Как представить сложный ресурс для записи REST?

Здравствуйте, В настоящее время у меня есть приложение, которое, когда пользователь нажимает "save", выполняет итерацию по всем элементам формы и создает один массовый объект, который управляет:

  var = params = [{ 
   attributes1: form1.getValues(),
   attributes2: form2.getValues(),  
.. ..
}];

Затем я отправляю этот массовый объект через RPC POST в мою модельную модель "Entity". Этот объект, который я хочу сохранить для данных, довольно сложный. В общем, данные распространяются примерно на 30 таблиц. Чтобы объяснить мой фактический вопрос, "сущность" - это здание (как в физическом собственном доме/доме/квартире).

Я бы хотел, чтобы я превратил свой беспорядок в RESTful API для сохранения свойств. Проблема заключается в том, что сохранение деталей для одной модели, которая охватывает одну таблицу, прекрасна. Как структурировать свой объект данных для транспорта, когда модель имеет

отношение многих ко многим
отношения от одного до многих.
отношения один к одному

Например:

Вот приведенная ниже версия того, что у меня может быть на свойство, и образцы данных

propertyId: 1,
locationId: 231234,
propertyName: "Brentwood",
kitchenFeatures: [
             { featureId: 1, details: "Induction hob"},
             { featureId:23, details: "900W microwave"}
],
propertyThemes: [ 12,32,54,65 ]

На самом деле это происходит намного больше, но вы можете получить общий смысл. kitchenFeatures будет примером множества-ко-многим, где у меня есть featureTable, который имеет все такие функции:

`featureId`, `feature`
1             "Oven Hob"  
23            "Microwave"

и свойствоThemes будут примером другого многого для многих.

Как я ожидаю, чтобы сформировать свой "объект" для моей службы RESTful? Возможно ли это?

т. Если я хочу сохранить это свойство, я бы отправил его:

http://example.com/api/property/1

Ответы

Ответ 1

Подход, который я буду использовать здесь, - это гипермедиа и ссылки:

/property
/property/{id}
/property/{id}/features/{id}

В зависимости от вашего домена вы даже можете уйти с:

/property/{id}/features/{name}

или

/property/{id}/features/byname/{name}

Таким образом, вы можете выполнять REST операции и обслуживать JSON или XHTML гипермедиа.

Сведения о недвижимости:

Request: GET /property/1
Response:
{
  ..
  "name": "Brentwood",
  "features": "/property/1/features"
  ..
}

Возможности Brentwood:

GET /property/1/features
{
  ..
  "Kitchen": "/property/1/features/1",
  "Dog Room": "/property/1/features/dog%20room",
  ..
}

GET /property/1/features/1
{
  ..
  "Induction hob": "/property/1/features/1/1",
  "900W microwave": "/property/1/features/1/23",
  "nav-next" : "/property/1/features/dog%20room",
  ..
}

Чтобы добавить отношение, вы можете сделать что-то вроде этого:

POST /property/1/features
{
  ..
  "Name": "Oven Hob"
  ..
}

Если вы знаете, каким будет отношение, вы используете PUT:

PUT /property/1/features/23
{
  ..
  "Name": "Oven Hob"
  ..
}

Вы можете обслуживать несколько типов носителей:

GET http://host/property/1/features/dog%20room.json

GET http://host/property/1/features/dog%20room.xhtml

Для ответа в xhtml ответ может использовать именованные ссылки:

..
 <a href="http://host/property/1/features/1" rel="prev">Kitchen</a>
..

Существуют и другие аспекты REST, которые вы можете использовать, например, код ответа, который я не использовал выше.

Таким образом, чтобы моделировать отношения, вы используете ссылки, которые могут быть сами по себе ресурсом, с которым можно работать с GET, PUT, POST и DELETE или даже с пользовательскими глаголами, такими как ASSOCIATE или LINK. Но первые четыре - те, к которым привыкли люди. Помните, что PUT idempotent, но не POST. Смотрите PUT vs POST в REST

Изменить: вы можете группировать свои ссылки в массивы JSON, чтобы придать структуру гипермедиа.

Ответ 2

Я думаю, что вы действительно спрашиваете: "Как представить сложные данные в форме, подходящей для передачи в POST?", правильно? Это меньше связано с REST и больше зависит от вашего выбора типа медиа. Я бы предложил начать с чистого представления JSON, используя массивы и поля ID с перекрестными ссылками для сопоставления отношений. Разумеется, вы также можете сделать это с помощью XML.

Примеры, которые вы дали, выглядят правильно на деньги. Вам просто нужно убедиться, что обе стороны (браузер и сервер) согласны с структурой и интерпретацией используемого вами типа мультимедиа.

Ответ 3

Я имею дело с тем же самым. Я решил не использовать идентификатор в любом месте, но использовать URL-адреса везде, где обычно ожидается идентификатор.

Итак, в вашем случае кухня может быть просто массивом с URL-адресами:

/feature/1
/feature/23

И темы для

/propertyTheme/12
/propertyTheme/32
etc..

В случае отношений "многие ко многим" мы обновляем все отношения в целом. Обычно мы просто сбрасываем существующие данные и вставляем новые отношения.

Для отношений от одного до многих мы иногда немного расширяем URL-адреса, где это имеет смысл. Если бы у вас была функция комментариев по "свойству", это могло бы выглядеть как

/property/1/comment/5

Но это действительно зависит от ситуации для нас, для других случаев мы помещаем ее в пространство имен верхнего уровня.

Это полезно для вас?