ScRsa

В целом удобная штука, если не требуется реализация какой-то сложной бизнес-логики, то возможностей Spring Data REST вполне хватает. Плюс из коробки есть фильтрация, пейджинация и даже поддержка HATEOAS. Проблем в взаимодействии с фронтендом на Angular/Vaadin не наблюдал.

если у вас Spring Boot, посмотрите на @EnableAuthorizationServer

Да, можно. Все что наследует интерфейс AutoCloseable можно использовать в try-with-resources

Нужно смотреть что это за "connectionPool"... Если это реализация DatSource, например получаемая из томката, или org.apache.commons.dbcp.BasicDataSource... То вызов метода close возвратит коннекшен обратно в пул. А если человек как то напрямую работает с пулом, то тут нужно бить по рукам

Как один из вариантов - можно сделать с аннотацией @OneToMany. Создать отдельное entity на таблицу PEOPLE_ATTRIBUTE, например

@Entity
@Table(name = "PEOPLE_ATTRIBUTE")
public class PeopleAttribute {
private int peopleCode;
private int attributeCode;
private String attributeValue;
...
}

@Entity
@Table(name = "PEOPLE")
public class People {

...
private Set<PeopleAttribute> attributes;

@OneToMany(mappedBy = "attribute")
public Set<PeopleAttribute> getAttributes() {
		return this.attributes;
	}
...
}

P.S. Небольшой совет из опыта: 1) всегда используйте Long для id сущностей, даже если вам кажется что short/int вам хватает, накладные расходы не такие уже и большие, не стоит экономить на спичках. 2) Если у вас @Id private int codePeople; является ID, то и называйте его peopleId, peopleID или просто id. Когда сущностей набирается много - начинается путаница и проблемы, особенно если в команде людей много и все пишут по разному.

Вот тутор от оракла, там всё поясняют. И ещё вот, например.
А вообще, с названиями классов в яве всегда были разногласия и путаницы. И часто DAO называют то, что им не должно являться.

По смыслу, DAO - довольно низкоуровневая штука, работает напрямую с хранилищем. Для каждого Transfer Object'а (сущности) должна быть реализация DAO для конкретного хранилища.
Например, есть 2 сущности: User и Post. Есть разные хранилища: 2 SQL базы данных (MySql и Postgres), файловая система, хранилище на основе xml-файлов.
Для объекта User есть интерфейс UserDao с методами CRUD. И должны быть 4 реализации этого метода: MySqlUserDao, PostgresUserDao, FileSystemStorageUserDao, XmlFileStorageUserDao. Аналогично для второй сущности. И обычно создаётся фабрика DAO, которая будет выдавать нужную реализацию (по первой ссылке есть схемы). Ну и в силу похожести реализаций, DAO обычно делают абстрактным и типизированным.
Таким образом, получается унифицированный интерфейс для манипуляции данными. Можно прозрачно сменить хранилище просто выбрав другую реализацию DAO (например, через внедрение зависимостей или конфигов), не меняя бизнес-логику.

Так что обычно DAO создают там, где нет готовой реализации связи с каким-нибудь хранилищем (или эта реализация не устраивает). А те же транкзакции - это более высокий уровень, в DAO их можно не включать, чтобы не усложнять архитектуру и монолитность.

Репозиторий же - это более общая и абстрактная штука.
Вообще, название "репозиторий" обычно встречается в мире спринга, в JavaEE другие термины. Да и суффикс DAO в спринге используется чаще, хотя по смыслу, это не всегда то самое DAO, в толковании Sun/Oracle.

Ну вообще говоря REST подразумевает отсутствие состояния - каждый запрос должен содержатб информацию, идентифицирующую пользователя (basic ,digest auth). Т.е. ваше клиентское приложение КАЖДЫЙ РАЗ вставляет в хидер запроса фаутентиикационные данны (логин/пароль), а приложение по этим данным "поднимает" пользователя из БД и возвразает релуьтат/запрещает доступ в зависимости от роли.
Второй варинат - использовать token-based аутентификацию/авторизацию (смотрите OAuth, JWT (JSON Web Tokens))
Третий вариант - использовать куки, и возможоно в вашей случае это будет оправдано. Если у вас оба клиента работают на том же домене/поддомене, то с кукой всё получится достаточно просто

Пожалуй поддержу Spring MVC. весьма удобная штука. Тут и инъекция зависимостей, и удобное создание бинов в scope(в общем вся мощь спринга). возможность прикрутить различные шаблонизаторы и ORM. Так что советую его