RESTful дизайн, как назвать страницы за пределами CRUD и др.?

Question

Я работаю над сайтом, на котором есть довольно много страниц, которые выходят за рамки моего ограниченного понимания дизайна RESTful, что по сути:

Create, Read, Update, Delete, Show, List

Вот вопрос: что такое хорошая система для обозначения действий / маршрутов, когда страница аккуратно не попадает в CRUD / show / list? Некоторые из моих страниц содержат информацию о нескольких таблицах одновременно. Я создаю сайт, который дает некоторым клиентам «домашнюю базу» после входа в систему. Он НЕ дает им никакой информации о себе, поэтому это не должно быть, например, / customer / show / 1. Там есть информация о компаниях, но на сайте есть и другие страницы, которые делают это по-другому. Что вы делаете, когда у вас есть такие ситуации? Эта «домашняя база» показывается клиентам и в основном содержит информацию о компаниях (но не уникально).

Второй случай: у меня есть таблица под названием «Совпадения» между клиентами и компаниями. Доступ к этим соответствиям совершенно разный в разных частях сайта (разные макеты, разные CSS-таблицы, разные типы пользователей, которые к ним обращаются и т. Д. Они не могут быть ВСЕМ совпадениями / показом. Как лучше всего маркировать другие?

Большое спасибо. =)

Answer 1

Я, конечно, не эксперт, но если вы переосмыслите свои ресурсы и будете относиться к ним более строго как к «существительным» или, по крайней мере, к спискам данных, возможно, будет проще встроить любое желаемое действие в GET, POST, PUT и УДАЛЯТЬ. Например, у вас есть ресурс /customers/, возможно, ресурс /customers/{username}/ для каждого клиента. Может быть, это дает им информацию о себе. Вы можете иметь /homebases/{username}/ или /customers/{username}/homebase/ в качестве ресурсов своей домашней базы. Предположительно, вы получите доступ к этому ресурсу homebase в основном через GET и POST, если там есть что обновить (чего я бы не ожидал от home-base или панели инструментов, поскольку это совокупный ресурс).

Для «сопоставлений» вы можете использовать что-то вроде /matchings/{customer},{company}/ (да, запятые и точки с запятой разрешены. Запятые обычно означают, что две части зависят от порядка, а точка с запятой означает независимый от порядка, хотя в этом нет никаких правил). Из этого ресурса вы можете иметь GET для чтения, отображения и перечисления любых необходимых вам данных (включая необязательные параметры запроса, передаваемые в качестве тела запроса GET), POST для обновления, PUT для создания и DELETE для удаления. Используя параметры, передаваемые в GET, вы также можете запрашивать разные представления одних и тех же данных. Конечно, вы можете иметь подресурсы такого соответствия, как /matchings/{customer},{company}/invoices/{invoice#}/.

Кстати, мне понравилась книга "RESTful Web Services" (2007 год, О'Рейли).

Я надеюсь, что это имеет смысл и полезно. =)

Answer 2

Совокупные и составные представления, я думаю, представляют собой серьезную проблему. Мне пришлось столкнуться с проблемой homepage, которая шла против всего, что я знал RESTful.

Мое решение состояло в том, чтобы рассматривать домашнюю страницу или информационную панель как ресурс сам по себе, но ресурс, где только операции GET имели смысл. POST / PUT / DELETE с домашней страницы, как обычно, были направлены на конкретные ресурсы.

Совпадения, напротив, кажутся более легкой проблемой для приручения. По вашему описанию это выглядит как простое сопоставление между Клиентами и Компаниями, и вы можете параметризовать его на основе параметров строки запроса.

/matchings?companies=X,Y,Z&locations=NY,CA,TX

Answer 3

Под дизайном RESTful я предполагаю, что вы имеете в виду веб-сервисы RESTful, поскольку архитектура на основе REST имеет гораздо более широкий смысл, чем эта.

Главное, что следует учитывать, это то, что архитектуры на основе REST основаны на протоколе HTTP практически во всех случаях. Поскольку HTTP определяет набор методов, иногда эти методы используются для создания так называемых веб-служб RESTful.

Но веб-сервисы RESTful не следуют никаким конкретным стандартам (в отличие от SOAP). Обычно используется:

• GET - для извлечения существующих предметов
• POST - для создания новых предметов
• PUT - для обновления существующих элементов
• УДАЛИТЬ - для удаления существующих элементов

Создание, чтение, обновление и удаление (CRUD) являются основными функциями любого постоянного хранилища.

Легко видеть, что в обычных веб-сервисах RESTful каждый HTTP-метод используется для соответствия одной из основных функций, но суть в том, что так быть не должно.

Есть и другие вещи, которые необходимо учитывать, URL-сопоставление - это одно из них (поскольку это вопрос вашего вопроса), безопасность - это другое. POST-запросы отправляют содержимое запроса в теле HTTP (которое может быть зашифровано), но GET-запросы отправляют его в URL-адресе, видимом для всех.

Если кто-то хочет разработать безопасный (зашифрованный) веб-сервис RESTful, он может сделать все запросы HTTPS POST, а затем указать в запросе, какую из операций CRUD нужно выполнить и на каких ресурсах.

Можно также расширить концепцию CRUD в более широком диапазоне, фактически, практически в каждом приложении.

Помните, что CRUD - это всего лишь четыре основные операции, на которых могут основываться все другие действия. Там нет никакого стандарта, которому вы должны следовать, вы можете указать свой собственный протокол, в соответствии с тем, что имеет смысл в вашем контексте, и учитывая все соответствующие соображения (безопасность, URL и т. Д.)

В частности, в отношении вашего вопроса у вас могут быть свои собственные действия, например show_by_x, show_by_y и т. Д. Полиция REST не собирается арестовывать вас: -)

Answer 4

REST и ORM - это две разные вещи, поэтому даже при том, что у вас есть модель с именем User, вам необходимо иметь ресурс пользователя. Управление ресурсами должно осуществляться на уровне контроллера рельсов

Думайте о ресурсах как о модулях / разделах

Пример: вы, возможно, захотите, чтобы ваши пользователи появлялись на странице панели мониторинга после входа в систему (и, скажем, у вас есть две категории пользователей: администраторы и обычные пользователи), поэтому вы можете иметь два ресурса:

admin_dashboard uer_dashboard

и оба могут иметь только действие чтения

Второй случай:

подумайте о том, чтобы иметь что-то похожее на пример выше (разные ресурсы в зависимости от уровня пользователя), если это возможно

Я не гуру ОТДЫХА, но надеюсь, это поможет: D

ура, Самера