[SPRING] 나머지 컨트롤러 vs spring-data-rest RepositoryRestResource

나머지 컨트롤러 vs spring-data-rest RepositoryRestResource

나는 이것이 이것이 중복 된 것처럼 느껴질 수 있음을 안다. @RestController 대 @RepositoryRestResource를 사용하는 경우 그러나 나는 그 문제에서 다루어지지 않은 몇 가지 것들을 가지고있다.

findAll () 및 findOne () 만 노출되고 다른 메서드는 필요하지 않으면 특히 삭제하십시오. 이것을 달성하기 위해 나는 이와 같은 것을 할 필요가있다.

    @RepositoryRestResource
    public interface ProductRepository extends MongoRepository<Product, String> {
      @RestResource(exported = false)
      @Override
      default void delete(String s) {
      }
      @RestResource(exported = false)
      @Override
      default void delete(Product product) {
      }
      @RestResource(exported = false)
      @Override
      default void delete(Iterable<? extends Product> iterable) {
      }
      @RestResource(exported = false)
      @Override
      default void deleteAll() {
      }
    }

나는 정말 원치 않는 코드가 많다고 생각합니다. 이것은 Rest Controller 방식으로하는 것이 훨씬 낫습니다.

이 모든 것을 감안할 때, HATEOAS를 제외하고는 스프링 - 데이터 - 나머지 (spring-data-rest)를 사용하는 것이 여전히 유리한가? 분명히하세요.

해결법

1. ==============================

   1.Spring-data-rest는 데이터 저장소를위한 REST 엔드 포인트를 제공하고 ALPS 메타 데이터, 검색 엔드 포인트 등을 포함한 모든 종소리와 휘파람을 제공합니다. 일반적으로 대부분의 유스 케이스를 다루며 사용자 정의를위한 기초를 제공합니다.

   Spring-data-rest는 데이터 저장소를위한 REST 엔드 포인트를 제공하고 ALPS 메타 데이터, 검색 엔드 포인트 등을 포함한 모든 종소리와 휘파람을 제공합니다. 일반적으로 대부분의 유스 케이스를 다루며 사용자 정의를위한 기초를 제공합니다.

   여기에 몇 가지 힌트가 있습니다.

   p.1에 관해서) - 수출 된 자원과 방법의 커스터마이징.

   실제로 하나만 내보내 지므로 @ deleteResource (exported = false)는 모든 delete (...) 메서드에 넣을 필요가 없습니다. void delete (Product entity). 관련 문서 장과 소스 코드를 살펴보십시오. 내가 뭔가를 놓치지 않으면 다음을 제공하면됩니다.

   내 보낸 저장소 방법에 대한 참고 사항. 때로는 매우 기본적인 (빈) Repository 저장소 인터페이스를 확장하고 저장소에서 허용하는 메소드 만 제공하는 것이 더 쉽습니다 (예 :

   @RepositoryRestResource
   public interface ProductRepository extends Repository<Product, String> {
     long count();
     Page<Product> findAll(Pageable pageable);
     Product findOne(String entity);
     <S extends Product> S save(S entity);
   }
   

   사용자 정의 컨트롤러 관련. 기본 동작을 사용자 정의하려면 @RespositoryRestController로 컨트롤러에 주석을다는 것이 가장 쉽습니다. 체크 아웃 문서와 RepositoryEntityController.java를 살펴보십시오. 이것이 기본 컨트롤러입니다.

   2 페이지 참조) 컨트롤러에서 ResponseEntity 리턴

   그것은 매우 힘이 빠릅니다. 엔티티를 Resource 로 랩핑하고 (예 : PersistentEntityResourceAssembler 사용)이를 사용하여 ResponseEntity를 작성할 수 있습니다. RepositoryEntityController.java 및 spring-restbucks와 같은 몇 가지 예를 참조하십시오.

   3 쪽) - 휴식 종점 테스트

   RepositoryRestResource를 노출하는 REST 엔드 포인트는 RepositoryEntityController (spring-data-rest의 일부)에서 구현된다.

   자신 만의 커스텀 컨트롤러를 구현한다면 평소와 같이 단위 테스트를 추가 할 수 있지만 PersistentEntityResourceAssembler를 사용하면 더욱 복잡해집니다.

   단위 테스트 예제 :

   public class FooControllerTests {
   
     @Mock
     PersistentEntityResourceAssembler assembler;
   
     @Mock
     PersistentEntityResourceAssemblerArgumentResolver assemblerResolver;
   
     @Mock
     PersistentEntity<Foo, ?> entity;
   
     @InjectMocks
     FooController fooController;
   
     @Mock
     FooService fooService;
   
     private MockMvc mockMvc;
   
     @Rule
     public MockitoRule rule = MockitoJUnit.rule();
   
     @Before
     public void setup() {
       this.mockMvc = MockMvcBuilders.standaloneSetup(fooController)
           .setCustomArgumentResolvers(assemblerResolver)
           .build();
     }
   
     @Test
     public void test_GetItem_Success() throws Exception {
       final Foo foo = new Foo();
   
       when(fooService.findOne(1)).thenReturn(foo);
       when(assemblerResolver.supportsParameter(any())).thenReturn(true);
       when(assemblerResolver.resolveArgument(any(), any(), any(), any())).thenReturn(assembler);
       when(assembler.toResource(foo))
           .thenReturn(PersistentEntityResource.build(foo, entity).build());
   
       this.mockMvc.perform(get("/foo/1")).andExpect(status().isOk());
     }
   }
   

   "Spring으로 REST 서비스 구축하기"튜토리얼도 참조.

   희망이 도움이됩니다.

from https://stackoverflow.com/questions/42962330/rest-controllers-vs-spring-data-rest-repositoryrestresource by cc-by-sa and MIT license