Spring Data Rest без HATEOAS

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

Добавьте это выше объявления класса, содержащего ваш основной метод:

@SpringBootApplication(exclude = RepositoryRestMvcAutoConfiguration.class)

Как указал Зак в комментариях, вам также необходимо создать контроллер, который предоставляет необходимые методы REST (findAll, save, findById и т. Д.).

Итак, вы хотите REST без того, что составляет REST? :) Я думаю, что пытаться изменить (читай: тупой) сервер RESTful для удовлетворения плохо спроектированной клиентской библиотеки - плохое начало. Но вот обоснование того, почему элементы гипермедиа необходимы для такого рода инструментов (помимо, вероятно, знакомого общее обоснование).

Предоставление доступа к объектам домена в Интернете всегда критически воспринималось большинством REST-сообщества. В основном по той причине, что границы объекта домена не обязательно являются границами, которые вы хотите предоставить своим ресурсам. Однако в последние пару лет фреймворки, обеспечивающие функциональные возможности каркаса (Rails, Grails и т. Д.), Стали чрезвычайно популярными. Итак, Spring Data REST пытается решить эту проблему, но в то же время быть хорошим гражданином с точки зрения спокойствия.

Итак, если вы в первую очередь начнете с простой модели данных (объекты без многих связей), хотите только их прочитать, на самом деле нет необходимости в чем-то вроде Spring Data REST. Контроллер Spring, который вам нужно написать, представляет собой примерно 10 строк кода поверх репозитория Spring Data. Когда все становится сложнее, история становится еще интереснее:

• Как написать клиента без жесткого кодирования URI (если да, то это не особо успокаивало)?
• Как вы справляетесь с отношениями между ресурсами? Как вы позволяете клиентам создавать их, обновлять и т. Д.?
• Как клиент обнаруживает, какие ресурсы запроса доступны? Как он узнает о передаваемых параметрах и т. Д.?

Если вы ответите на эти вопросы: «Моему клиенту это не нужно / он не способен на это», то Spring Data REST, вероятно, для начала неправильная библиотека. То, что вы в основном создаете, - это JSON через HTTP, но тогда ничего действительно успокаивающего. Это совершенно нормально, если это служит вашей цели, но использование библиотеки с четкими ограничениями дизайна во что-то произвольно отличающееся (хотя и внешне похожее), которое эффективно игнорирует именно эти аспекты дизайна, - это, в первую очередь, неправильный подход.