Comments 29
REST? не, не слышал
Дяденька, вы бы хоть почитали и попробовали вникнуть перед тем как комменты такие оставлять.
Сыночек, я прочитал и вникнул.
А вот вам советую прочитать поглубже и узнать, что такое REST кроме index+show+edit+update+new+create+destroy.
есть сущность, у неё есть url /entities. вычленить из запроса API это, web или mobile вы можете многими способами, будь то параметры, заголовки или на крайний случай поддомен. но url должен быть машиночитаемым и обозначать тип сущности.
А вот вам советую прочитать поглубже и узнать, что такое REST кроме index+show+edit+update+new+create+destroy.
есть сущность, у неё есть url /entities. вычленить из запроса API это, web или mobile вы можете многими способами, будь то параметры, заголовки или на крайний случай поддомен. но url должен быть машиночитаемым и обозначать тип сущности.
<< Сыночек, я прочитал и вникнул.
Давай с этим остановимся. Мы тут не для этого собрались.
Рест как был так и остался, и урлы как были читаемыми так и остались и так же обозначают тип сущности. При этом сами они находятся в разных namespace. Здесь говорится именно о внутренней организации.
Рельсы на это:
resources :users do
resources :posts
end
контроллеры UsersController и PostsController.
Я предлагаю UsersController, и Users::PostsController.
Поэтому мне не понятен ваш выпад, который к теме внутренней организации не имеет прямого отношения.
Давай с этим остановимся. Мы тут не для этого собрались.
Рест как был так и остался, и урлы как были читаемыми так и остались и так же обозначают тип сущности. При этом сами они находятся в разных namespace. Здесь говорится именно о внутренней организации.
Рельсы на это:
resources :users do
resources :posts
end
контроллеры UsersController и PostsController.
Я предлагаю UsersController, и Users::PostsController.
Поэтому мне не понятен ваш выпад, который к теме внутренней организации не имеет прямого отношения.
я это понимаю. я к тому, что вы написали, что у вас в приложении есть web в скопе, и есть api, mobile и админка в namespace'ах. итого:
/users/1/posts
/api/users/1/posts
/mobile/users/1/posts
/admin/users/1/posts
зачем, если можно сделать один рест-контроллер, и уже к примеру CanCan'ом смотреть, с каких запросов что разрешать смотреть, что редактировать и т.д.?
/users/1/posts
/api/users/1/posts
/mobile/users/1/posts
/admin/users/1/posts
зачем, если можно сделать один рест-контроллер, и уже к примеру CanCan'ом смотреть, с каких запросов что разрешать смотреть, что редактировать и т.д.?
Я не стал затрагивать эту тему потому что это отдельный разговор.
В простых приложениях да сработает один контроллер в котором мы что то выбираем. Но один канкан тут не спасет. В вебе результатом может быть редирект в mobile еще что то, в апи что то свое. В больших приложениях респонды превращаются в ад, сама логика может быть сложной и зависеть от варианта использования. Список постов может быть общедоступным (по юзеру) и у него будет один дизайн, а может быть список в аккаунте и там совершенно все по другому. Версий апи бывает несколько. Ну и опять же ифы ифы ифы.
К такому разделению я пришел не сразу, но сейчас говорю про то что это работает, но не утверждаю что это единственный путь.
В простых приложениях да сработает один контроллер в котором мы что то выбираем. Но один канкан тут не спасет. В вебе результатом может быть редирект в mobile еще что то, в апи что то свое. В больших приложениях респонды превращаются в ад, сама логика может быть сложной и зависеть от варианта использования. Список постов может быть общедоступным (по юзеру) и у него будет один дизайн, а может быть список в аккаунте и там совершенно все по другому. Версий апи бывает несколько. Ну и опять же ифы ифы ифы.
К такому разделению я пришел не сразу, но сейчас говорю про то что это работает, но не утверждаю что это единственный путь.
Для перенаправлений и прочего был создан respond_to и format'ы.
View вообще очень гибкая тема, и не является аргументом.
Версии api — вообще спорный вопрос. Моё имхо, вот эти версии — этакое google-java legacy. REST API как раз был придуман, чтобы избегать этих зоопарков версий, перенесённых из XML-RPC. И статья Freelancing Gods здесь не аргумент. Ребята молодцы, но лучшее, что они написали — это Thinking Sphinx, в код которого достаточно заглянуть, чтобы больше не читать их статьи.
И вообще, все известные евангелисты так называемого Rails Way уже устали твердить, что отдельная админка для приложений — моветон.
View вообще очень гибкая тема, и не является аргументом.
Версии api — вообще спорный вопрос. Моё имхо, вот эти версии — этакое google-java legacy. REST API как раз был придуман, чтобы избегать этих зоопарков версий, перенесённых из XML-RPC. И статья Freelancing Gods здесь не аргумент. Ребята молодцы, но лучшее, что они написали — это Thinking Sphinx, в код которого достаточно заглянуть, чтобы больше не читать их статьи.
И вообще, все известные евангелисты так называемого Rails Way уже устали твердить, что отдельная админка для приложений — моветон.
«Для перенаправлений и прочего был создан respond_to и format'ы.»
Как я уже сказал, это не работает если мы говорим про большое приложение.
«И вообще, все известные евангелисты так называемого Rails Way уже устали твердить, что отдельная админка для приложений — моветон.»
Это собственно тоже не аргумент. Я на конкретных примерах показал конкретный профит и рассказал плюсы и минусы. Этот подход используется в десятках проектах на rails и он приносит свои плоды.
В любом случае мы друг друга не переубеждаем, а обозначаем свои позиции. Я понял вашу, надеюсь вы поняли мою.
Как я уже сказал, это не работает если мы говорим про большое приложение.
«И вообще, все известные евангелисты так называемого Rails Way уже устали твердить, что отдельная админка для приложений — моветон.»
Это собственно тоже не аргумент. Я на конкретных примерах показал конкретный профит и рассказал плюсы и минусы. Этот подход используется в десятках проектах на rails и он приносит свои плоды.
В любом случае мы друг друга не переубеждаем, а обозначаем свои позиции. Я понял вашу, надеюсь вы поняли мою.
Версии API используются даже в гитхабе, а там вполне образцовое применение, ИМХО. API там вообще сказка.
Конечно, неизвестно, как оно сейчас изнутри сделано, но версии, как таковые, присутсвуют — и никто не пытается отправлять POST запросы напрямую на github.com/username/projectname/issues/add.xml или что то подобное.
Конечно, неизвестно, как оно сейчас изнутри сделано, но версии, как таковые, присутсвуют — и никто не пытается отправлять POST запросы напрямую на github.com/username/projectname/issues/add.xml или что то подобное.
угу. и в третьей версии они как раз перешли на чистый REST API без всяких /api/ и /v2/ в запросах
Ага а фейсбук ушел с реста на graph api.
Это все лишь означает что для них это работает лучше. Тут как и везде, нет серебряной пули.
Это все лишь означает что для них это работает лучше. Тут как и везде, нет серебряной пули.
в том, что они называли REST API, от REST было только название.
в Graph API гораздо больше рестоподобности. в общем-то он фактически и является REST'ом за исключением того, что они не разбивают сущности на типы, а сразу делают graph.facebook.com/ENTITY_ID/(action|subresource)
в Graph API гораздо больше рестоподобности. в общем-то он фактически и является REST'ом за исключением того, что они не разбивают сущности на типы, а сразу делают graph.facebook.com/ENTITY_ID/(action|subresource)
«рестоподобности»
«общем-то он фактически и является REST'ом»
«за исключением того, что они не разбивают сущности на типы»
«но url должен быть машиночитаемым и обозначать тип сущности.»
Так все таки рест или не рест?)
Вопрос на самом деле риторический, понятно что все что есть это некое приближение к ресту.
«общем-то он фактически и является REST'ом»
«за исключением того, что они не разбивают сущности на типы»
«но url должен быть машиночитаемым и обозначать тип сущности.»
Так все таки рест или не рест?)
Вопрос на самом деле риторический, понятно что все что есть это некое приближение к ресту.
Ага, а «api.» в имени домена уже в запрос не входит.
А разгадка одна — желание сделать код как можно более легким для поддержания. CanCan — норм, когда речь идет о простых вещах. Сложные контроллеры порождают кучу условных фильтров, мусорных спецификаций (типа блоков respond_to) и соотношение неполезного кода к полезному становится не в пользу последнего. Некоторых людей это раздражает.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
А почему все забывают про respond_with? Кода меньше в разы а результат тот-же и не нужно городить кучу сущностей.
Ну и presenters добавить не забываем.
Про respond_to никто не забывает. Полезная штука. Но, к сожалению, тоже не универсальная.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Интересное решение задачи, но, по-моему, feed и mobile несколько иного рода группировка чем, например, api.
Не имеет смысла дублировать контроллеры когда можно выводить ответ (response) в разных форматах и использовать соответствующие типы шаблонов. Если же задача состоит в инкапсуляции или изоляции данного раздела приложения, удобнее вывести часть кода в движок (engine).
Не имеет смысла дублировать контроллеры когда можно выводить ответ (response) в разных форматах и использовать соответствующие типы шаблонов. Если же задача состоит в инкапсуляции или изоляции данного раздела приложения, удобнее вывести часть кода в движок (engine).
Имеет. Как я уже выше написал в сложных и больших приложениях респонды начинают только усложнять и запутывать. В вебе у вас может быть выбрано очень много данных для разных блоков, в mobile немного. Уже нужно разделять, а все может быть и гораздо сложнее.
Мой посыл в том что эта схема работает когда сложность приложения высокая, для большинства проектов это конечно же избыточно.
Мой посыл в том что эта схема работает когда сложность приложения высокая, для большинства проектов это конечно же избыточно.
У меня аналогичная схема организации контроллеров, только не ApplicationController, а Base контроллер и у меня «форматы ответа» не отражаются в иерархии, там скорее «точки зрения» на приложения или упрощенно — роли пользователей. Пока что работает идеально и новые фичи имплементятся прекрасно — с cancan разделением «ролей» было бы хуже — проверяли.
Спасибо, интересный подход. А еще если активно юзать inherited_resources, то вообще круто.
Оффтоп, но подскажите, что за шрифт у вас на скриншотах?
хм, вероятно это дефолтный убунтовский habrahabr.ru/blogs/ubuntu/105239/
Спасибо, и правда он.
Sign up to leave a comment.
Иерархия контроллеров