Применяете дизайн RESTful ко всему сайту?

Все это может показаться новичком, но я пытаюсь обдумать дизайн сайта, который полностью ОТДЫХАН. Я понимаю, как применять дизайн RESTful к таким вещам, как «Пользователи», «Фотографии», «Сообщения в блогах» и т. Д., Потому что считаю их «объектами».

Но как насчет страницы "о нас". Что это за ресурс такой? Это даже ресурс в RESTful смысле этого слова? Также, скажем, я захожу на URL "http://www.example.com/", какой ресурс я запрашиваю? Индексный ресурс?

Наиболее распространенный шаблон ресурса веб-сайта RESTful, который я вижу, - это добавление представления в URI:

/ resourcetype / identifier [/ view ] [/ page] [? filterparams]

Когда нет представления , вы просто используете представление по умолчанию. В твоем случае:

• / - запрос на example.comвозврат возвращает представление по умолчанию для ресурса верхнего уровня - вашего сайта.
• / aboutus - вид «О нас» ресурса верхнего уровня. Или, в качестве альтернативы, aboutusможет быть именованным идентификатором ресурса в области CMS верхнего уровня. *
• / Customers / 1 / aboutus - в этом запросе указывается вид «О нас», ориентированный на клиента 1 .

При этом иногда лучше немного выдумать для лучшей семантики. Например, StackOverflow использует RESTful / questions / [id] для вопросов, но страница Задать вопрос - это / questions / ask, которая не очень RESTful ( askне является questionsресурсом), но имеет большой смысл использовать простых смертных.

^{* В CMS на верхнем уровне тип ресурса часто, но не всегда, удаляется, поскольку он избыточен.}

Имейте в виду, что дизайн RESTful сам по себе призван обеспечить стандарт, с помощью которого сеть становится единообразно программируемой. Это не всегда уместно и не полезно делать из всего вашего сайта, обращенного к человеку, чисто семантику REST.

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

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

TL; DR : REST - это инструмент. Используйте это, когда и где это полезно, но не связывайтесь с этим.

Но как насчет страницы «о нас» [?] Что это за ресурс?

Сложный. Ничего плохого в ресурсе, который имеет компоненты, части или структуру.

Ресурсы не являются «строками реляционной базы данных» или другими атомарными вещами. Они ресурсы.

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

Это даже ресурс в RESTful смысле этого слова?

Да.

Также, скажем, я захожу на URL "http://www.example.com/", какой ресурс я запрашиваю?

Нет.

Вы просите ресурс "aboutus". Возможно (но странно), чтобы ресурс был единичным. Нет идентификатора и не «список».

http://www.example.com/aboutus/?format=xml

Возвращает сложный XML-документ с множеством частей и частей. В этом нет ничего плохого.

Индексный ресурс?

Не имеет большого значения в смысле "RESTful". Индексная страница предназначена для людей. Приложение, которое использует RESTful API, предназначено для запроса определенных видов ресурсов.

Я хотел бы, чтобы мой взгляд был независимым от серверной части. Вы можете запросить у бэкенда ресурсы, такие как вещи, которые идут на аккордеоне, панель навигации и другие объекты, которые относятся к телу. Однако вы должны оставить обработку этих представлений ресурсов своему клиентскому коду, который в конечном итоге отобразит их в соответствии с требованиями.

Ресурс "О нас" - это ... Us :) er, You. Подумайте об атрибутах Тебя, которые вы хотите опубликовать, и сверните их как существительное с представлением.

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