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

Question

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

Create, Read, Update, Delete, Show, List 

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

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

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

Answer 1

Я конечно не эксперт, но если вы пересмотреть свои ресурсы и думать о них более строго, как «существительных» или, по крайней мере, списки данных, это может быть проще, чтобы соответствовать любое желаемое действие в GET, POST, PUT и DELETE. Например, у вас есть ресурс /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), кстати.

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

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 - для обновления существующих элементов
• DELETE - для удаление существующих предметов

Создание, чтение, обновление и удаление (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 - это две разные вещи, из-за этого, хотя у вас есть модель под названием «Пользователь», вы необходимо, чтобы иметь ресурс пользователей.Ресурсы должны управляться на уровне рельсов контроллера

Think ресурсы в качестве модулей/секций

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

admin_dashboard uer_dashboard

и оба могли только прочитать Действие

Второй ча себе:

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

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

приветствий, Sameera