Закладка AngularJS frontend (прямой доступ) - Spring Data Rest backend

Question

Я начал реализовывать интерфейс веб-интерфейса для управления службой RESTful, обслуживаемой Spring Data Rest по традиционной реляционной БД. Это делается с AngularJS и библиотекой angular-hal, которую я нашел, очень хорошо подходит к философии и формализму Spring Data RestHATEOAS.

Например, мне просто нужно знать первую конечную точку API ('/'), а затем все мои запросы выполняются через отношения, не заботясь о URL-адресах. Проблема заключается в том, чтобы иметь возможность прямого доступа к странице, отображающей одно из моих объектов.

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

Но я не могу получить доступ непосредственно к странице с информацией о контакте: ресурс вводится из контроллера списка в контроллер редактирования, а контроллер редактирования не может узнать URL-адрес для запроса, если не указан контроллер списка.

Корневая проблема заключается в том, что с Spring Data Rest, организации не имеют открытое поле для их id (не в формате JSON) и хранилищ не имеют API relation поиска по идентификатору.

Я думал о некоторых решениях, но я не люблю их.

1. Работа вокруг в бэкэндом

• Добавить Projection методом getId() для всех объектов, которые должны быть закладкой
• Добавьте соответствующий findById() в интерфейсе хранилища
• Используйте id в URL-адресе frontend в качестве параметра (или пути) и разрешить ресурс, вызывая новое доступное отношение поиска.
• Недостатки: это заставляет нас вручную вручную восстанавливать все DTO с помощью Spring Data Rest, поэтому мы теряем одну из целей фреймворка.
• Вопрос: есть ли способ настроить Spring для автоматического раскрытия этих полей id и методов findById?

2. Используйте само отношение

• Получить собственного URI хозяйствующего субъекта с angular-hal$href('self') методом
• Используйте его в качестве параметра страницы и решить ресурс, вызвав новый halClient.$get(resourceUri) на нем
• Недостатки: uri должен быть обработан до и после beeing, помещенный в URL-адрес страницы, чтобы предотвратить ошибки из-за anothe r "http: //" в адресной строке. Я подумал о том, чтобы сделать на нем кодировку base64, но это потребляет.
• Недостатки: это предоставляет URL-адрес API миру, и эти данные могут быть критическими и должны оставаться скрытыми (даже если это будет доступно через отладчик, наблюдающий за сетевым трафиком).

3. Забудьте о HATEOAS

• Не связывайтесь с отношениями и возможностью обнаружения
• Удаляет angular-hal и просто использовать $resource с простыми старыми URL-адрес отображения
• Недостатками : это идет назад и чувствует, что не следуют руководящим принципам ...

Итак, я что-то упустил? Какова наилучшая практика доступа к данным в полной среде RESTFul HATEOAS?

Answer 1

Я нашел методы exposeIdsFor, которые позволяют добавить поле, аннотированное с помощью @Id в JSON.

@Configuration 
public class RepositoryConfiguration extends SpringBootRepositoryRestMvcConfiguration { 

    /** 
    * add here the main resources that would need direct access from outside 
    */ 
    @Override 
    protected void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) { 
     config.exposeIdsFor(Contact.class, User.class); 
    } 
} 

Тогда я сделал все сущности, я хочу ид подвергаться воздействию наследоваться от общего абстрактного класса

@MappedSuperclass 
public abstract class AbstractEntity { 

    @Id @GeneratedValue 
    Long id; 

    public Long getId() { 
     return id; 
    } 

    public void setId(Long id) { 
     this.id = id; 
    } 
} 

это абстрактный класс обслуживаемой @NoRepositoryBean хранилище

@NoRepositoryBean 
public interface AbstractEntityRepository<T extends AbstractEntity> extends JpaRepository<T, Long> {  
    @RestResource(rel = "byId") 
    T findById(@Param("id") Long id); 
} 

и затем я могу разоблачить как id, так и метод byId() для объектов, которые мне волнуют:

@Entity 
public class Contact extends AbstractEntity { 

    @Column 
    String name; 

    @Column 
    String email; 
} 

public interface ContactRepository extends AbstractEntityRepository<Contact> {  
} 

Я думаю, что это неплохая работа и позволяет прямой доступ сущностей от клиента по небольшой цене