Частные уровни зрелости API REST и дополнительные уровни сложности

Question

Это мой первый проект на основе REST, в настоящее время использующий Spring для разработки.Когда я начал изучать и внедрять REST, я чувствую, что начинаю немного переоценивать его для закрытого API, который по сути является CRUD, в основном он будет обслуживать только веб-приложение.

Я не чувствую этогоздесь лучше всего используется концепция ресурса, а также HATEOAS (уровень зрелости 3) чувствует себя немного неловко, поскольку внутренние и внешние отделы работают в одном офисе, и я не думаю, что проект будет масштабироватьсяскажем, до уровней Amazon, где будет светить HATEOAS, HAL, кажется, тоже усложняет ситуацию и не дает нам никаких преимуществ.

В течение этого периода я понимал, насколько мощным является REST для публичного API, но в нашем случае, в качестве частного API, я не вижу преимуществ.С каким мышлением я должен подходить к дизайну частного API с учетом архитектуры REST (если REST даже необходим)?

Answer 1

Это очень мнительный вопрос, поэтому возьмите все, что здесь написано, с крошкой соли.

По моему мнению , уровень зрелости 3не имеет смысла для внутреннего API.Если вы можете контролировать и обновлять свои клиенты API, гибкость, добавленная HATEOAS, не оправдывает добавленную сложность протокола.Как вы указали, главное преимущество HATEOAS проявляется, когда вы не контролируете своих клиентов.

По моему мнению, остановка на уровне зрелости 2 достаточно хороша для вашего сценария.

Но опять же, я не полностьюпонять ваш контекст и ваши требования к развитию.