Лучшие практики для сопоставления ресурсов RESTful с существующими доменами

Question

Мы собираемся создать некоторые RESTful-сервисы, которые по сути станут переходом к некоторым устаревшим веб-сервисам на основе SOAP. Сервисы SOAP более обобщены и будут использоваться во всей нашей организации (по крайней мере, таков план). Услуги RESTful предназначены для конкретных клиентов. Это решение уже принято и, к сожалению, я не могу его изменить ...

Мы боремся с тем, как структурировать наши ресурсы RESTful так, чтобы это имело смысл, следовало бы рекомендациям REST и вызывало эти службы SOAP, не причиняя себе слишком большой боли.

У нас есть некоторая свобода в отношении уровня детализации для серверных служб, но общее мнение таково: держите их в общих чертах и ​​не приспосабливайте их к потребностям конкретного клиента.

Это приводит к некоторым интересным проблемам. Например, как обращаться с дочерними ресурсами родителя. Типичный пример, с которым мы работали: клиент с дочерним адресом.

У нас есть внутренний SOAP-сервис, который обновляет клиента как единое целое. Однако клиенту служб REST может потребоваться обновить только адрес для выставления счетов. Как нам лучше всего обрабатывать последующие обновления дочернего ресурса?

Должны ли мы делать обновления на «родительском» уровне (клиент) или предоставлять более детальную REST-операцию, которая обрабатывает адрес как ресурс и обновляет его таким образом? Последнее кажется правильным, ОТЛИЧНЫМ способом. Но если мы сделаем это, мы, по сути, будем вызывать грубую серверную службу только для одного фрагмента обновления. Кажется, не имеет смысла, поскольку это довольно тяжелый вызов.

Мы также немного боремся с тем, как соотнести ресурсы RESTful с нашей внутренней моделью домена. Мы могли бы заботиться о ресурсе RESTful как об одном объекте, но в нашем домене на внутреннем сервере это может быть множество различных объектов. Сейчас у нас есть относительно простая таблица БД, чтобы справиться с этим, но я не уверен, что она будет масштабироваться, когда мы сопоставляем все больше и больше ресурсов с объектами домена.

Это всего лишь пара примеров того, что мы поражаем ... Мне интересно, сталкивался ли кто-нибудь с подобными проблемами и имел ли какие-либо слова совета или мог бы указать мне на некоторые статьи, которые могли бы иметь некоторые лучшие практики.

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

Большое спасибо!

Answer 1

Я обнаружил, что большинство доменов, которые я моделирую, очень легко отображаются в REST. Самое важное, что нужно сделать, это войти в правильное состояние ума. REST моделирует домены как набор ресурсов, где SOAP стремится подчеркнуть набор действий. Другой способ взглянуть на это заключается в том, что REST фокусируется на состояниях, а SOAP - на переходах между состояниями. Еще проще, вы можете думать о REST как о существительных, а о SOAP как о глаголах. Я знаю, что это не идеальная аналогия, но она полезна для меня.

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

Я не думаю, что неуместно обновлять весь клиент только для того, чтобы обновить адрес, но не знаком с вашим доменом, возможно, так оно и есть. Если вы хотите специально взаимодействовать с адресом, просто создайте подресурс (или вложенный ресурс). В итоге вы получите следующее отображение URL и глаголов:

GET /customer/72/address    # return the address of customer with id 72
PUT /customer/72/address    # update the address of customer with id 72

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

Если у вашего клиента есть коллекция какой-то сущности, скажем, виджетов, вы можете отобразить взаимодействия следующим образом:

GET     /customer/72/widgets        # return the widgets of customer with id 72
POST    /customer/72/widgets        # create a new widget for customer with id 72
GET     /customer/72/widgets/158    # return widget with id 158 of customer 72
PUT     /customer/72/widgets/158    # update widget with id 158 of customer 72
DELETE  /customer/72/widgets/158    # delete widget with id 158 of customer 72

Просто имейте правильное мышление и имейте в виду, что сопоставление не будет однозначным, и у вас все будет хорошо.

Answer 2

Не пытайтесь смоделировать ваши доменные объекты как ресурсы.Смоделируйте ваши взгляды / варианты использования в качестве ресурсов.Нет ничего плохого в создании ресурсов для конкретных клиентов.REST поощряет случайное повторное использование, то есть неожиданное повторное использование, оно не предлагает вам пытаться создавать ресурсы, которые будут работать для каждого возможного сценария.

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

В общем, я предпочитаю использовать грубые ресурсы, просто потому, что именно для этого оптимизирован HTTP.