doc/EA/REST/readme.md

### REST API
- Передача подходящего состояния, Representational State Transfer — «передача репрезентативного состояния» или «передача состояния представления» [wiki](https://ru.wikipedia.org/wiki/REST)
- [Секреты создания эффективного REST API: гайд для системных аналитиков ПСБ](https://habr.com/ru/companies/psb/articles/949246/)
#### framework
- [Разработка RESTful API: как использовать ExpressJS и другие фреймворки для создания RESTful API](https://habr.com/ru/articles/768976/)
  - REST (Representational State Transfer) — это архитектурный стиль, разработанный Роем Филдингом в диссертации 2000 года.
Он представляет собой набор ограничений и принципов, используемых для построения распределенных систем. 
  - RESTful API — это вариант веб-сервиса, который соответствует принципам REST. Он предоставляет возможность взаимодействия с сервером через стандартные HTTP-методы (GET, POST, PUT, DELETE), используя четко определенные маршруты и структуру URL.

#### intro
- [Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)](https://habr.com/ru/articles/770226/)
- [GraphQL лучше REST](https://habr.com/ru/articles/427601/#comment_19294165) достаточно признать очень простой факт — и то и то — **RPC over http.**  
  Просто в одном случае есть конкретика (формат, протокол если хотите) а во втором — его нет. То есть в целом решая те же проблемы что решает graphql (удобная композиция данных для клиента) вы переизобретете оный (возможно в более приятном для вас виде). Как пример — json api в целом еще в версии 1.0 предлагал очень похожие плюшки, просто масштабы были не те и приоритеты другие.  
OpenAPI, Swagger и т.д. — это лишь попытка формализовать описание контрактов. Причем ни graphql ни сваггер в этом плане не являются универсальными решениями.  
использование YAML вместо JSON улучшает «сапортабилити» в разы.
- [RESTful API — большая ложь](https://habr.com/ru/articles/265845/)
- [Давайте поговорим про Web-API](https://habr.com/ru/articles/955574/)