ФорумПрограммированиеPHP для идиотовPHP и ООП → Концепция Resource-Method-Representation

Концепция Resource-Method-Representation

  • artoodetoo

    Сообщения: 5139 Репутация: N Группа: в ухо

    Spritz 28 июля 2012 г. 4:21

    Некий Paul James предложил свою концепцию веб-приложений в статье Introducing the RMR Web Architecture примерно год назад. В англоязычном интернете есть отклики, в русском ничего не нашел. Вы не поверите, на хабре еще не успели рассказать об этой штуке. :) А по моему стоит познакомиться.
    Затрудняюсь дать адекватный русский перевод, пусть будет Ресурс-Метод-Репрезентация чтобы избежать пересечения с "представлением" 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 - фреймворк автора, где он наверное воплотил что-то вроде того
    ιιlllιlllι унц-унц
  • kostyl

    Сообщения: 5203 Репутация: N Группа: Джедаи

    Spritz 28 июля 2012 г. 5:09, спустя 47 минут 56 секунд

    Те же яйца только сбоку )) Какое фунционально отличие от MVC? Общее в RMR и MVC - уровень программной абстракции над HTTP! В итоге - разницы никакой, только MVC остается гибче просто потому что RMR не плевать на определение URL.
  • artoodetoo

    Сообщения: 5139 Репутация: N Группа: в ухо

    Spritz 28 июля 2012 г. 5:28, спустя 18 минут 25 секунд

    1. RMR что-то вроде адаптации MVC к REST. А REST уважает URL )))
    2. Разница в "месте отрыва". В MVC не очевидно что оставлять в Контроллере, а что в Модели. В предлагаемой философии всё понятно — это всё единый Ресурс, имеющий определенные Методы.
    В общем порядка больше, улыбка шире.
    ιιlllιlllι унц-унц
  • kostyl

    Сообщения: 5203 Репутация: N Группа: Джедаи

    Spritz 28 июля 2012 г. 5:36, спустя 8 минут 6 секунд

    artoodetoo, порядка больше, тут согласен!
  • adw0rd

    Сообщения: 22905 Репутация: N Группа: в ухо

    Spritz 28 июля 2012 г. 5:48, спустя 12 минут 36 секунд

    Класс ресурса

    CBV в Django
    Спустя 269 сек.

    class SomeResource(View):

    def get(self, request):
    return HttpResponse(content)

    def put(request):
    raise HttpResponseNotAllowed

    def post(request):
    raise HttpResponseNotAllowed

    def delete(request):
    raise HttpResponseNotAllowed
    Спустя 75 сек.
    Я так понял единственная фича это роутинг как в рельсах лет 5 назад?
    Спустя 122 сек.
    Репрезентация
    Response mixin
    adw/0
  • artoodetoo

    Сообщения: 5139 Репутация: N Группа: в ухо

    Spritz 28 июля 2012 г. 5:51, спустя 2 минуты 22 секунды

    adw0rd, унаследован от View? у джанги свои представления о прекрасном.
    ιιlllιlllι унц-унц
  • phpdude

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 28 июля 2012 г. 16:50, спустя 10 часов 58 минут 51 секунду

    Чаще всего я использую (по порядку): ListView, DetailView, TemplateView, View, FormView, CreateView, UpdateView, RedirectView, DeleteView

    В МЕМОРИЗ НАХ
    Сапожник без сапог
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 29 июля 2012 г. 6:12, спустя 13 часов 21 минуту 55 секунд

    По мне так RMR это строгая обертка над MVC для REST и подобных строгих, линейных API.
    В джанго View не совсем мапятся на Resource.

    Это всё делается обычно так:
    * Resource строится на базе модели
    * Method - это handler Http-метода во View (в django View это контроллер в привычном MVC)
    * Representation - это отдельный рендер результатов. Json, xml, и т.д.


    Примеры ресурсов в REST-надстройках:
    http://django-tastypie.readthedocs.org/en/latest/tutorial.html#creating-resources
    http://django-rest-framework.org/examples/blogpost.html#creating-the-resources

Пожалуйста, авторизуйтесь, чтобы написать комментарий!