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

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

Create, Read, Update, Delete, Show, List

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

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

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

Ответ 1

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

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

Мне понравилась книга "RESTful Web Services" (2007 O'Reilly), кстати.

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

GET - для извлечения существующих элементов
POST - для создания новых элементов
PUT - для обновления существующих элементов
DELETE - для удаления существующих элементов

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

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

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

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

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

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

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

Ответ 4

REST и ORM - это две разные вещи, из-за этого, хотя у вас есть модель под названием "Пользователь", вам необходимо было иметь ресурс пользователей. Ресурсы должны управляться на уровне контроллера rails.

Рассматривайте ресурсы как модули/разделы

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

admin_dashboard uer_dashboard

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

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

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

Я не гуру REST, но надеюсь, что это поможет: D

веселит, sameera