Затрудняюсь дать адекватный русский перевод, пусть будет Ресурс-Метод-Репрезентация чтобы избежать пересечения с "представлением" view в MVC. Русского человека поджидают и другие трудности перевода. Например автор часто использует слово model как глагол: "оформлять" или "моделировать", а не как эм-ви-си-шная "Модель"
RMR описывается как некая техника, согласующаяся с REST, но противопоставленная MVC.
Сразу дам псевдокод, мы же программисты. Ничто так не мотивирует на чтение как добрый кусок
request = readRequestData();
resource = loadResourceForThisRequest(request.url);
response = callRequestMethod(request, resource);
response.output();
А теперь послушаем автора почему этот код НЕ MVC, а нечто другое. Автор источает яд:
Насколько я понимаю, MVC не подходит для Интернета, он не представляет ресурсы должным образом (роутинг сделан адски зло, экшены-методы контроллеров выглядят как ресурсы, тогда как на самом деле URL это и есть сам ресурс).
Он просто не работает с ресурсами, основной элемент Веба полностью игнорируется. Так как же можно это исправить?
* ты может забыл, а я напомню. URL означает Uniform Resource Locator, то есть что-то там про ресурсы.
* В обсуждениях я встретил такую формулировку: MVC использует УРЛ как глагол, а удобнее считать его существительным.
Все согласятся с тем, что разделение кода на функциональные части это хорошая идея. Каждый кусок выполняет свою часть работы и позволяет нам сконцентрироваться на своей задаче. Так как же нам попилить работу лучше, чем это описывает MVC?
Ресурс
Начнем с ресурсов. Интернет состоит из ресурсов, поэтому, чтобы сделать наши веб-приложения, мы должны оперировать ресурсами. Ресурсы это объекты в RESTful-системе, они содержат информацию, они уникально адресуются идентификатором (URL в HTTP), и имеют стандартный интерфейс (в HTTP стандартные методы это GET, PUT, и т.д.).
Таким образом, в ОО языке, HTTP-ресурс можно рассматривать как объект с приватными переменными-членами, а также набором публичных методов, которые соответствуют стандартным методам HTTP. С точки зрения MVC ресурс может рассматриваться как Модель с некоторым набором Контроллеров в придачу.
Метод
Каждый запрос автоматически достигает ресурса, т.к. каждому ресурсу соответствует уникальный URL-адрес, а метод ресурса соответствует методу запроса HTTP. Подобно Контроллеру MVC, метод выполняет все подготовительные операции для ответа на запрос.
Репрезентация
И наконец ответ. В RESTful приложении ресурсы отдаются клиенту в Репрезентации, то есть в формате, подходящем для данного запроса.
К примеру эта веб-страница, которую Вы смотрите в данный момент, это "Статья" в виде HTML. Могут быть другие репрезентации: Вы могли бы просмотреть эту статью в текстовом файле или PDF документе, если бы я подготовил их для вас.
Таким образом, чтобы получить Репрезентацию, мы добываем объект-ресурс и говорим ему в каком формате отдать данные.
Точка входа
* Автор использует термин front controller, а я перевел вот так, чтобы опять же, блеать, не создавать ненужных параллелей с Controller MVC.
Ок, нам нужна точка входа чтобы обрабатывать все входящие запросы и маршрутизировать их на обработку (тот же код, что и сверху):
request = readRequestData();
resource = loadResourceForThisRequest(request.url);
response = callRequestMethod(request, resource);
response.output();
Довольно похоже на точку входа в MVC , мы читаем запрос и делаем что-то в зависимости от того что имеем. Главный вопрос в том, откуда мы получим ресурс для данного URL?
Класс ресурса
Для примера мы запрограммируем базовый класс ресурса:
class Resource
{
private resourceData = [];
method constructor(request, dataSource) {
// load data from data source
}
method get(request) {
return new Response(200, getRepresentation(request.url, resourceData));
}
method put(request) {
return new Response(405);
}
method post(request) {
return new Response(405);
}
method delete(request) {
return new Response(405);
}
}
Класс засасывает данные в своем конструкторе и затем отдает их в одном из методов. Методы соответствуют PUT, POST и DELETE и возвращают объект со статусом 405 (Method Not Allowed) т.к. по умолчанию мы не хотим никак изменять данные. Метод GET должен вернуть Репрезентацию, соответствующую URL и уже добытым данным этого ресурса.
Маршрутизация
Финальная часть паззла это роутинг входящих запросов на соответствующие им классы ресурсов. Тут вы можете выбирать на своё усмотрение.
Мы следуем соглашению, что адрес вида /comething соответствует классу с именем Something. А для множества ресурсов мы создаем отображение URL /comething/item на класс коллекции ресурсов SomethingItem.
Заключение
Итак, имея пучок ресурсных классов, некие варианты Репрезентации плюс правило маршрутизации, вы можете выстроить RESTful приложение. А если добавите немного плюшек от HTTP типа условных GET-запросов и специальных заголовков про кеш, и у вас получится что-то хорошее.
* Introducing the RMR Web Architecture - оригинал статьи
* Tonic - фреймворк автора, где он наверное воплотил что-то вроде того