REST: как создать ресурс, который зависит от трех или больше ресурсов различных типов?

Question

REST: как создать ресурс, который зависит от трех или больше ресурсов различных типов?

Ваша проблема, кажется, недостающее пространство между Вашими двумя классами в CSS:

.area1.item
{
    color:red;
}

Должен быть

.area1 .item
{
    color:red;
}

7

rest

задан Rich Apodaca 10 September 2009 в 01:55

2 ответа

Другие вопросы по тегам:

rest

Похожие вопросы:

score 1 · Answer 1

Хорошо, теперь я понимаю, где вы видите дублирование. Возможно ли выполнить POST следующее?

{
  "shipment":{
    "created_at": "Wed Sep 09 18:38:31 -0700 2009",
    "order":{
      "uri":"http://example.com/orders/815"
      },
    "packer":{
      "uri":"http://example.com/packers/42",
    }
    "destination":{
      "uri":"http://example.com/destinations/666",
    }
  }
}

и вернуть это

{
  "shipment":{
    "created_at": "Wed Sep 09 18:38:31 -0700 2009",
    "order":{
      "name":"the order to which this shipment belongs",
      "uri":"http://example.com/orders/815",
      "media_type":"application/vnd.com.example.store.Order+json"
    },
    "packer":{
      "name":"the person who packed this shipment",
      "uri":"http://example.com/packers/42",
      "media_type":"application/vnd.com.example.store.Packer+json"
    },
    "destination":{
      "name":"the destination of this shipment",
      "uri":"http://example.com/destinations/666",
      "media_type":"application/vnd.com.example.store.Destination+json"
    }
  }
}

Возможно, это просто не работает в JSON, но я делаю нечто подобное с XML в своих ресурсах. Идея состоит в том, что вы можете передать серверу «ссылку» на ресурс с заполненным только URI, а сервер заполнит остальные данные в объекте.

score 2 · Answer 2

"Иерархии" REST ничего не означают . Они удобны для навигации, чтобы показать отношения в форме пути. Не иерархия как таковая , а путь. Таким образом, вариант 2 действительно имеет смысл, если вы отбросите концепцию «иерархии» и признаете, что существует множество альтернативных путей к одному и тому же конечному местоположению.

Ваш вариант 2: заказы-> упаковщики-> путь назначения. Теоретически заказы-> пункты назначения-> упаковщики и упаковщики-> заказы-> пункты назначения, упаковщики-> пункты назначения-> заказы, а также некоторые другие лидеры в одном месте. Да, поддерживать их всех - это боль. Однако это доказательство того, что все они эквивалентны и , что нет иерархии.

«Мне не нравится вариант 1, потому что [он] не кажется очень СУХИМ.

Итак? Избавьтесь от повторяющихся вещей. Почему отгрузка также должна содержать полное повторение информации о заказе и упаковщике? Ссылки URI достаточны, чтобы разрешить поиск и получение Order и Packer. Зачем вообще отправлять Order и Packer?

«Вариант 3 усложняет изучение системы». Для кого? Разработчики? Вы проектируете свою систему вокруг разработчиков, а не пользователей и их вариантов использования? К стыду.

Смысл REST (обычно) в том, что URI - это абсолютная, окончательная и вечная вещь. Какая альтернатива дает вам абсолютно лучшую структуру URI? Помните, что URI - это не иерархии, а пути - и объекты могут существовать в конце нескольких альтернативных путей.