https://bcho.tistory.com/807 REST API에 대한 보안 REST API 보안 조대협 REST API에 대한 보안에 대해서 알아보자. API 에 대한 보안은 인증, 메세지 암호화, 무결성 크게 3가지 관점에서 고민해볼 수 있다. 1) 인증 인증은, REST API를 호출한 사람(클라이 bcho.tistory.com

이번에 상속 관계를 정의함으로써 Wardrobe, Cloth, Record 엔티티의 중복 기능인 댓글 기능과 좋아요 기능을 슈퍼 타입 엔티티인 PostEntity로 이관시키는 리팩토링을 진행했다. 문제 발생 공통 로직들을 각각의 Service가 아닌 PostServcie로 이동시키는 작업을 진행하고 있었는데, 댓글 달기 메서드인 writeComment()에서 StackOverflowError가 터지면서 로직이 중단되는 상황이 발생했다. StackOverflowError를 발생시키는 부분은 SLF4J에서 엔티티의 toString()을 호출하며 발생하는 부분이였다. 엔티티의 toString()을 추가 시켜주는 부분은 lombok의 @Data이기 때문에 이 부분에 문제가 있을 것이라 판단하였다. 문제 원인 @..

나만의 옷장 서비스에 Entity인 Wardrobe(옷장), Cloth(옷), Record(코디)는 댓글이 달릴 수 있고, 좋아요가 눌릴 수 있는 동일한 특징을 가지고 있다. 그래서 Entity인 Like(좋아요)와 Comment(댓글)에 Wardrobe, Cloth, Record가 속성으로 모두 포함하고 Wardrobe, Cloth, Record 각각에 모두 Like와 Comment를 포함하는 식으로 구현을 하였다. 물론 기능은 정상 동작하지만 과연 이 방법 밖에 없는 것인가 의문이 생겼다. 이런식으로 구현하게 되면 중복 코드가 굉장히 많아지고 또 동일한 특징을 가진 Entity가 추가 되면 Comment와 Like와 관련된 로직을 또 다시 작성해야 하는 상황이 발생하게 된다. 이렇게 되면 굳이 Hib..

수십, 수백만개의 데이터를 한번에 반환한다면..? API를 개발하다 보면 데이터 리스트를 반환하는 상황이 무조건 발생한다. 그런데 만약에 아무런 조치 없이 데이터 리스트를 반환한다고 생각해보자. 몇십, 몇백개의 데이터를 처리하는데는 큰 상관이 없지만 몇십만, 몇 백만개의 데이터를 반환하게 되면 문제가 발생할 수 밖에 없다. 이러한 상황을 방지하기 위해 우리는 API 설계시에 페이징 로직을 필수적으로 적용시켜야 한다. 페이징을 적용한 API 구현 예시 다음은 나만의 옷장 서비스에서 페이징을 적용한 옷 리스트를 반환하는 API 구현 예시이다. @Setter @Getter public class ResponseForClothes extends PaginatedResponse { private List cont..

JSON의 무한 순환 구조는 왜 발생할까? 나만의 옷장 서비스의 REST API 구현하면서 가장 고생한 부분이다. 개발 초반에는 아무 생각 없이 DTO를 활용하지 않고 Entity를 직접 컨트롤러에서 반환했는데 객체가 또 다른 객체를 호출하고 그 객체가 또 다른 객체를 호출하는 무한 호출 현상이 발생했다. 예를 들어 무한 호출 현상을 대충 표현하자면 a { b { c { } } }  이런 식으로 a안에 b가 포함되어 b의 필드가 출력되고, 또 b의 필드에 c가 포함되어 c의 필드가 출력되고 만약에 c의 필드에 또다시 a필드가 포함되어 있다면 무한 호출 현상을 볼 수 있다. 결국에 서버가 죽어버리는 상황을 맞이하게 된다. 위와 같이 무한 순환 구조가 발생하는 이유를 파악하기 위해서는 우선 객체를 JSON..