Здравствуйте, pagrus, Вы писали:

P>Недавно довелось услышать идею построения SOA системы на REST сервисах. Мне приходилось строить такую на веб-сервисах, но глубокого опыта использования REST нет — увы.

Сайты клепать доводилось? Вот Вам и глубокий опыт использования REST

P>И поэтому возникают разные вопросы. К примеру, концептуальный — уживаются ли две модели мира, где в одной мир состоит из сервисов, а в другой — из ресурсов?

Легко уживаются. Примерно как две перпендикулярные прямые.

SOA — идеология. Состоит в основном из заповедей вида "не делай так" и "не делай эдак". Очень похожа по своей сути на шаблоны объектно-ориентированного программирования.
REST — один из вариантов проектирования интерфейса сервиса.

ООП же не запрещает паттерн Repository? Не запрещает. Вот точно также SOA не запрещает REST.

Если с сервисом проще общаться в терминах ресурсов или если клиенты сервиса просто не умеют ничего другого, кроме HTTP-запросов (как JavaScript, например) — делаем сервису REST-морду. Если интерфейс лучше описывается в RPC-стиле (это обычно означает наличие некоего состояния на стороне сервиса) или если есть какие-то другие предпосылки (скажем, интерфейс обязательно должен быть дуплексным) — делаем сервису SOAP-морду (ну или CORBA-морду, или DCOM-морду). А бывает, что делаем и две морды сразу.

P>Или практические — как задать чёткий контракт для rest-сервиса? Как на основании этого контракта строить клиентскую часть?

А зачем? Все обычно бегут от SOAP-а к REST-у, как раз намучившись с вечно разъезжающимися и дублирующимися схемами и неймспейсами. Т.е. отсутствие строгой типизации считается даже скорее преимуществом REST.

Если клиент и сервис написаны на одном и том же языке программирования — проблема решается расшариванием кода классов запросов/ответов.
А в противном случае URL-ы и форматы запросов/ответов можно и в wiki описать.

P>Интересуют не столько рассуждения, сколько практический опыт разрабатываемых, а лучше внедрённых систем.

Да вот примерно так и живем, как описал выше.