look-forest

HATEOAS클라이언트가 서버가 제공하는 하이퍼미디어 링크와 상호 작용하여 웹 서비스의 리소스를 동적으로 탐색할 수 있도록 하는 REST 아키텍처의 제약 조건 ( Self-descriptive messages,  Dynamic navigation, Discoverability )애플리케이션의 상태 정보에 따라 링크 정보가 동적으로 바뀜이러한 HATEOAS를 만족시켜야 진정한 REST API 다!스프링 HATEOAS이 프로젝트는 Spring, 특히 Spring MVC로 작업할 때 HATEOAS 원칙을 따르는 REST 표현을 쉽게 생성할 수 있는 몇 가지 API를 제공한다.링크를 만드는 기능문자열 가지고 만들기 ( new link() )컨트롤러와 메소드에 달려있는 url로 만들기 ( linkTo() )리소스..

# 테스트할 것JSON 응답이 201로 나오는지입력 값 제한 # 구현 코드 API 응답 컨트롤러@RestController@ResponseBody를 모든 메소드에 적용한 것과 동일하다ResponseEntity를 사용하는 이유응답 코드, 헤더, 본문 모두 다루기 편한 API객체를 JSON으로 변환ObjectMapper 사용DTO를 Entity로 변환ModelMapper 사용 (Bean으로 등록해야 함)@Configurationpublic class AppConfig { @Bean public ModelMapper modelMapper() { return new ModelMapper(); } 입출력 값 제한입력값 제한 - DTO와 ModelMapper 활용id 또는 입력 받은 데..

REST API란?REpresentational State Transfer API(Application Programming Interface)REST 아키텍처 스타일을 따르는 API시스템 제각각의 독립적인 진화를 보장하기 위한 방법Representation 이란?REST API에서의 "Representation(표현)"은 특정 리소스의 상태를 클라이언트에 전달하기 위해 사용되는 데이터의 형식을 말한다. 클라이언트는 서버로부터 필요한 리소스를 요청하고, 서버는 해당 리소스의 현재 상태를 나타내는 데이터를 클라이언트에게 보내줄 때, 클라이언트가 받는 이 데이터가 바로 "Representation".REST에서 리소스는 고유한 URL로 식별되며, Representation은 주로 JSON, XML 등의 형식..

트랜잭션 전파가 필요한 이유Service단에서 트랜잭션 하나만 사용할 경우클라이언트 A만 생각하면 MemberService 에 트랜잭션 코드를 남기고, MemberRepository , LogRepository 의 트랜잭션 코드를 제거하면 깔끔하게 하나의 트랜잭션을 적용할 수 있다.하지만 이렇게 되면 클라이언트 B, C가 호출하는 MemberRepository , LogRepository 에는 트랜잭션을 적용 불가!트랜잭션 전파 없이 이런 문제를 해결하려면 트랜잭션이 있는 메서드와 트랜잭션이 없는 메서드를 각각 만들어야 한다.이런 문제를 해결하기 위해 트랜잭션 전파가 필요한 것이다.트랜잭션 전파 활용스프링은 @Transactional 이 적용되어 있으면 기본으로 REQUIRED 라는 전파 옵션을 사용한다..

트랜잭션을 각각 사용하는 것이 아니라 트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 수행하면 어떻게 될까?이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라 한다.스프링은 다양한 트랜잭션 전파 옵션을 제공한다.전파 기본지금부터 설명하는 내용은 트랜잭션 전파의 기본 옵션인 REQUIRED 를 기준으로 설명한다. 외부 트랜잭션이 수행중인데, 내부 트랜잭션이 추가로 수행될 경우, 스프링에서 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어준다 (커넥션 1개) . 내부 트랜잭션이 외부 트랜잭션에 참여하는 것이다. 이것이 기본 동작이고, 옵션을 통해 다른 동작방식도 선택할 수 있다 (커넥션을 새로 생성하는 경우) . 스프링은 이해를 돕기 위해 논리 트랜잭션과 물리..

스프링 트랜잭션 기본스프링 트랜잭션 추상화JDBC 기술과 JPA 기술은 트랜잭션을 사용하는 코드 자체가 다르다. 따라서 JDBC 기술을 사용하다가 JPA 기술로 변경하게 되면 트랜잭션을 사용하는 코드도 모두 함께 변경해야 한다.스프링은 이런 문제를 해결하기 위해 PlatformTransactionManager 라는 인터페이스를 통해 트랜잭션을 추상화한다. 선언적 트랜잭션과 AOP@Transactional 을 통한 선언적 트랜잭션 관리 방식을 사용하게 되면 기본적으로 프록시 방식의 AOP가 적용된다.트랜잭션 프록시가 트랜잭션 처리 로직을 모두 가져간다. 그리고 트랜잭션을 시작한 후에 실제 서비스를 대신 호출한다.트랜잭션 프록시 덕분에 서비스 계층에는 순수한 비즈니즈 로직만 남길 수 있다.스프링은 트랜잭션 ..

추상화 비용Spring Data Jpa를 적용해서 리포지토리를 아래와 같이 구성한 경우,중간에서 JpaItemRepositoryV2 가 어댑터 역할을 해준 덕분에 ItemService 가 사용하는 ItemRepository 인터페이스를 그대로 유지할 수 있고 클라이언트인 ItemService 의 코드를 변경하지 않아도 되는 장점이 있다. 그런데, 구조를 맞추기 위해서 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단 점이 생겼다. 추상화도 비용이 든다. 이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화를 도입하는 것이 실용적이다. 실용적인 구조DI, OCP 원칙을 지키지 못하더라도, 상황에 따라 단순하고 빠르게 구현하고 추후 필요시 추상화로 리팩토링 할 수 있다. ..

QUERY의 문제점 : QUERY는문자,Type-check불가능. 실행하기 전까지 작동 여부 확인 불가만약SQL이 클래스처럼 타입이 있고 자바코드로 작성할 수 있다면?  QueryDSL JPA, MongoDB, SQL같은 기술들을 위해 쿼리를 Java로 type-safe하게 개발할 수 있게 지원하는 프레임워크주로 JPA쿼리(JPQL)에 사용. JPQL builder 역할.쿼리+도메인+특화+언어쿼리에 특화된 프로그래밍  언어컴파일 에러, IDE 자동완성 지원!JPQL로 해결하기 어려운 복잡한 쿼리는 네이티브 SQL 쿼리 사용 (QueryDSL -> JPQL -> SQL)DSL도메인+특화+언어특정한 도메인에 초점을 맞춘 제한적인 표현력을 가진 컴퓨터 프로그래밍 언어  Querydsl 활용Spring Data..