Правильно ли я понял принципы REST?

Question

[Кот Учёный]

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

1. SSL
   
2. Сессий нет, и на бэкенде не предусмотрена соответствующая логика.
   
3. После авторизации выдаётся токен.
   
   1. Которому допустимо (?) устанавливать срок актуальности.
      
   2. Который допускается писать в куку для хранения у клиента,
      
   3. Но который обязан быть явно передан в каждом запросе, требующем соответствующих разрешений.
      
   4. В отличие от сессии, куда записываются данные об авторизованном пользователе и ещё Бог весть о чём, данные остаются там, где им и положено быть — в БД (ну, или в кеше запросов), а токен является ключом для доступа к этим данным.
      
4. Читать и писать куки может только фронтэнд.
   
5. Мне нужен ACL, и за него, конечно же, будет отвечать сервер, если надо, отказывая клиенту соответствующими заголовками и сообщением в теле ответа. Сервер принимает запрос и токен и определяет права пользователя на запрошенную операцию, конечно же, применимо к указанному ресурсу или экземпляру.
   
6. Итого — логика бэкенда заключается лишь во взаимодействии с БД и в ACL, не более того.
   
7. Вся бизнес-логика — на фронте.
   
8. Может быть, фронтенд при необходимости будет хранить своё состояние самостоятельно, а может быть, я в этом месте просто обойдусь кешированием HTTP-запросов. Но, в любом случае, кеширование должно быть (там, где оно может быть и желательно).

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

Answer 1

[Сергей Протько]

Читать и писать куки может только фронтэнд.

Нет, так как это вполне себе stateless механизм. Он действует как токен.

Мне нужен ACL, и за него, конечно же, будет отвечать сервер

403 статус код. Все остальное опционально.

Итого — логика бэкенда заключается лишь во взаимодействии с БД и в ACL, не более того.

зависит от проекта.

Вся бизнес-логика — на фронте

Зависит от проекта. Если у вас пользователи никак не взаимодействуют друг с другом и нет общих данных - то да. В этом случае вам даже бэкэнд не нужен особо. Достаточно завернуть в мидлвэр rest интерфейс к какой монге.

А если есть общее для нескольких пользователей состояние то вам придется часть бизнес логики вынести на сервер. Он будет выступать в роли единого источника правды.

Может быть, фронтенд при необходимости будет хранить своё состояние самостоятельно,

Rest только про взаимодействие клиента и сервера. Ему без разницы что там делает клиент или что там делает сервер.

Довольно хорошо принципы и ограничения описывающие restful описаны тут:

www.restapitutorial.ru/lessons/whatisrest.html

к сожалению вся остальная информация не полная. Например нет упоминаний как работать с PATCH методом.

Comments

[Кот Учёный]

> А если есть общее для нескольких пользователей состояние то вам придется часть бизнес логики вынести на сервер. Он будет выступать в роли единого источника правды.

Я вижу необходимость в этом только для ACL или для логики, которая будет использовать что-нибудь типа вебсокетов. То есть, совместный доступ к данным — это юрисдикция ACL. а обмен состоянием — это, в абстрактном представлении, условно-P2P-взаимодействие, где бэкенд при необходимости должен нагружаться только проксирующей (и, возможно, валидирующей) логикой, но не сверх необходимости. Или я что-то упустил?

[Сергей Протько]

Кот Учёный: повторюсь. Есть разные проекты и разные требования. В моих проектах сделать все p2p будет безумно сложно и проще вынести бизнес логику на клиент. С другой стороны в некоторых проектах можно вообще без бэкэнда обойтись как вы и описываете.

Вы сейчас говорите о проекте где от бэкэнда не требуется ничего сложнее CRUD-а. таких проектов пожалуй процентов 90%.

Answer 2

[Оптимус Пьян]

https://habrahabr.ru/post/46032/
https://habrahabr.ru/post/50147/
https://habrahabr.ru/post/38730/

https://habrahabr.ru/search/?q=%5BREST%5D&target_t...