| Сколь я понимаю идею мистера Фильдинга, она состоит в упрощении создания и работы сервиса. Конечно, можно иметь один обработчик на группу URL. На этом форуме как-то был вопрос:"У меня в REST на один адрес приходят три разных XML сообщения. Как узнать какое сообщение пришло не разбирая его полностью?". Автору был предложен один из вариантов решений с сообщением, что у него вовсе не REST. Конечно же один обработчик может принимать много адресов - предельный случай это контроллер в web слое, реализующем MVC. С такой точки зрения приложение, использующее Ext JS является одним огрмным REST сервисом (хотя требование об отсутсвии состояния здесь не выдерживается). Предположим всё таки, что наш REST сервис удовлетворяет условию простоты. В случае обычной работы web слоя и сервлета контроллера первая часть адреса это "сервер->контроллер", а вторая определяет обработчик, генерирующий ресурс. Параметры запроса мы передаем некоторым СТАНДАРТНЫМ образом. Обратившись к REST сервису мы видим НЕ СТАНДАРТНОЕ описание дийствий обработчика, когда даже смысл использованния HTTP запросов (например, POST) размыт и может быть в разных организациях разным. Но, как уже упоминались количество типов HTTP запросов недостаточно, и мы начинаем добавлять в адрес компоненты, кодирующие нужные операции обработчика и параметры. Ресурсом может быть и документ, и вызов метода, которому могут понадобиться фактические параметры - это ведь типично для сервиса? Поместим их в тело в виде JSON? Какую часть служебной нформации помещать в адрес, а какую в тело? Здорово, что REST сервис может быть реализован свободным образом! Однако в сложных случаях свобода оборачивается негативными последствиями. Разработка REST сервисов из индустриального процесса превращается в искусство. Бог с ним с функционалом - он зависит от проблемной области, хотя и здесь есть типовые решения (DAO). Суть вопроса также не в способе функционирования микросервисов, а в том, что их много. А интерфейс взаимодействия с REST сервисом зависит от воображения разработчика и плохо поддается стандартизации. К тому же сервисы работают не только в рамках одной организации и REST вовсю функционируют в глобальной сети. Отказывшись по причине "простоты", желанной свободы, или (извините) моды, от SOAP на смену получили для сервиса неопределенный и почти не поддающийся стандартизации интерфейс. Самое паршивое, когда разработчик полагает, что использует REST, а на смом деле "лепит" для работы в глобальной сети что-то собственное "ужасно правильное", не понимая сути REST, или превращает URL адрес в свалку неструктурированной информации. |
)