RESTful Много-ко-многим возможно? - PullRequest
Новая
       5

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

11 голосов
/ 24 марта 2011

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

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

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

Затем я отправляю этот массовый объект через POST RPC моей службе модели "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 будет примером типа «многие ко многим», где у меня есть таблица FeaturesTable, которая имеет все функции, например, так: 

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

, а свойство Themes будет примером другой функции «многие ко многим».многие.

Как я могу сформировать свой "объект" для моей службы RESTful?Это вообще возможно?

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

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

Ответы [ 3 ]

10 голосов
/ 02 апреля 2011

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

/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 идемпотент , но не POST.См. PUT против POST в REST

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

3 голосов
/ 25 марта 2011

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

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

2 голосов
/ 30 марта 2011

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

Так что в вашем случае kitchenfeatures может быть просто массивом с URL-адресами: 

/feature/1
/feature/23

И темы для 

/propertyTheme/12
/propertyTheme/32
etc..

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

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

/property/1/comment/5

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

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

...