[TIL] 내일배움캠프 100일차(23.08.22.) - HTTP 메서드, CORS, @NoArgsConstructor(access = AccessLevel.PROTECTED), @Transactional(readonly=true)

To-do

• 기술면접 대비 공부
• 최종 프로젝트 회의 -> 역할 분담, 일정 및 진행상황 공유
• 최종 프로젝트 작성 -> 권한 나누기 -> 추가 기능 및 예외처리, 페스티벌 게시 요청글 CRUD / 소셜로그인 기능 코드 리뷰(오류 해결)
• 원티드 프리온보딩 백엔드챌린지 9월 과제 수행

 

---

TIL

< HTTP 메서드 >

• HTTP 메서드란 클라이언트와 서버 사이에 이루어지는 Request와 Response 데이터를 전송하는 방식을 일컫는다. 각 메소드는 특정 작업을 수행하고 리소스를 다루는 역할을 담당하며, RESTful API나 웹 개발에서 활발하게 사용된다.

주요 메소드	기능
GET	데이터를 조회
POST	데이터를 생성
PUT	데이터 전체를 업데이트
PATCH	데이터 일부를 업데이트
DELETE	데이터를 삭제

기타 메소드	기능
HEAD	GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS	대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT	대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE	대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 메소드란 클라이언트와 서버 사이에 이루어지는 request와 response 데이터를 전송하는 방식을 나타내며, 메소드의 종류는 총 9가지로 주요 메소드로는 데이터를 조회하는 GET, 데이터를 생성하는 POST, 데이터 전체를 업데이트 하는 PUT, 데이터 일부를 업데이트 하는 PATCH, 데이터를 삭제하는 DELETE 등이 있습니다. 각 메소드는 특정 작업을 수행하고 리소스를 다루는 역할을 담당하며, RESTful API나 웹 개발에서 활발하게 사용됩니다.

참고 블로그: https://inpa.tistory.com/entry/WEB-🌐-HTTP-메서드-종류-통신-과정-💯-총정리

---

< CORS(Cross Origin Resource Sharing) >

• Origin(출처): Protocol + Host + Port

• SOP(Same-Origin Policy, 동일 출처 정책): 동일한 출처에서만 리소스를 공유할 수 있다. 악의적인 경우를 방지하기 위해 사용되는 정책. -> 다른 출처에 있는 리소스를 가져와 사용하는 일을 무턱대고 막을 수 없으므로 몇 가지 예외 조항을 두고 허용하는 경우를 지정해뒀는데, 그 중 하나가 바로 CORS 정책을 지킨 리소스 요청이다.
• CORS (Cross-Origin Resource Sharing, 교차 출처 리소스 공유)는 웹 애플리케이션에서 다른 도메인(Origin) 간에 리소스를 공유하는 것을 가능하게 하는 보안 메커니즘. 위의 SOP에 의해 기본적으로 브라우저는 같은 출처 (Origin)에서만 요청한 리소스에 접근할 수 있도록 제한되어 있다. 그러나 웹 애플리케이션에서 외부 도메인과 데이터를 교환하는 경우, CORS는 이를 허용하고 안전하게 관리하는 방법을 제공
• CORS는 서버와 클라이언트 간의 HTTP 헤더를 사용하여 제어된다. 클라이언트는 요청 시 HTTP 헤더에 Origin을 포함시키고, 서버는 응답에 특정한 헤더를 포함시켜 어떤 도메인의 요청을 허용할지 결정. 이를 통해 다른 도메인 간의 통신을 허용하는 동시에, 보안상의 문제나 악의적인 요청을 방지
• 요약하면, CORS는 다른 출처간의 리소스 공유를 허용하며, 웹 애플리케이션의 보안을 유지하는 데 중요한 역할!

CORS (Cross-Origin Resource Sharing)는 웹 애플리케이션에서 다른 출처 간에 데이터를 안전하게 공유하기 위한 보안 메커니즘입니다. 브라우저는 동일 출처 정책에 따라 다른 도메인 간의 요청을 제한하는데, CORS는 이를 허용하기 위해 클라이언트와 서버 간에 특정 헤더를 교환합니다. 이를 통해 안전한 데이터 공유가 가능하며, 웹 애플리케이션의 보안을 유지합니다.

참고 블로그: https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏

---

 

< @NoArgsConstructor(access = AccessLevel.PROTECTED) >

• @NoArgsConstructor(access = AccessLevel.PROTECTED)를 권장하는 이유

1. 객체 생성의 안전성 제고: @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용하면 생성자의 접근 제한자가 protected로 설정된다. 이로써 외부에서 이 생성자를 직접 호출하여 객체를 생성하는 것을 방지할 수 있다. 객체 생성 로직을 더 명시적으로 제어할 수 있으며, 외부로부터의 불필요한 접근을 막을 수 있다.
2. 빌더 패턴과의 호환성: @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용하면 객체 생성 시 빌더 패턴과 잘 결합된다. 객체 생성 로직은 protected 생성자를 통해 제어하고, 빌더 패턴을 사용하여 원하는 속성을 설정할 수 있다.
3. 상속과 확장성: @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용하면 해당 클래스를 상속하는 하위 클래스에서 기본 생성자를 사용할 수 있도록 한다. 이를 통해 클래스의 확장성을 높일 수 있다.
4. 객체의 일관성 유지: 생성자는 객체의 상태를 초기화하고 일관성을 유지하는 역할을 한다. 외부에서 생성자를 무작위로 호출하는 것을 제한함으로써, 객체의 유효한 상태를 유지하고 예기치 않은 초기화를 방지할 수 있다.
5. 코드 가독성과 유지보수성: 생성자의 접근 제한자를 protected로 명시하는 것은 클래스의 인스턴스 생성 방법을 더 명확하게 표현하는데 도움이 된다. 또한, 이로 인해 객체 생성 로직의 의도를 더 쉽게 파악할 수 있으며 코드 유지보수성을 높일 수 있다.

요약하면, @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용하면 객체 생성의 안전성과 명확성을 제고할 수 있어서 권장되는 방법. 클래스의 역할과 상황에 따라서 적절한 방식을 선택하는 것이 중요하며, 코드의 가독성과 안정성을 고려하여 사용하자.

참고 블로그: https://cobbybb.tistory.com/14      https://oh-sh-2134.tistory.com/107

---

< @Transactional(readonly=true) >

• 데이터 조회 시 @Transactional(readonly=true)를 사용하는 이유는 데이터베이스 조회 연산에 대한 최적화를 위한 것. 이 옵션을 사용하면 해당 메소드 내에서 수행되는 데이터베이스 작업이 읽기 전용이라는 것을 명시적으로 나타내며, 이를 통해 JPA 구현체가 더 효율적으로 조회 작업을 처리할 수 있도록 도와준다.
• @Transactional(readonly=true) 사용 시 이점

1. 성능 최적화: 읽기 전용 트랜잭션은 더 나은 성능을 제공할 수 있습니다. 데이터베이스는 해당 트랜잭션 중에 변경사항을 추적하지 않아도 되기 때문에 더 가볍고 빠르게 처리될 수 있습니다.
2. 데이터 일관성: 읽기 전용 트랜잭션에서는 데이터를 변경하지 않기 때문에 다른 트랜잭션에서의 변경 사항에 영향을 받지 않습니다. 따라서 조회 중에 발생하는 데이터 일관성 문제를 줄일 수 있습니다.
3. 데이터베이스 옵티마이저 최적화: 일부 데이터베이스 시스템은 읽기 전용 트랜잭션에 대해 더 나은 쿼리 실행 계획을 생성할 수 있습니다. 이로 인해 쿼리 성능이 향상될 수 있습니다.
4. 락 회피: 읽기 전용 트랜잭션에서는 락을 사용하지 않아도 되기 때문에 다른 트랜잭션과의 충돌이 줄어듭니다. 이는 병행성을 높여 더 많은 동시 접근을 처리할 수 있게 해줍니다.
5. 가독성 향상: 코드를 작성하는 개발자는 @Transactional(readOnly=true)이 설정된 메서드가 DB에서 데이터를 읽기만 한다는 것을 명확하게 확인할 수 있고 이로 인해 코드의 가독성이 향상됩니다.

 

• @Transactional(readonly=true) 주의사항

해당 메소드 내에서 데이터베이스에 변경사항을 수행하려고 하면 에러가 발생합니다. 읽기 전용 트랜잭션 내에서 다른 트랜잭션과의 충돌을 피하는 것이 목표이므로, 가능한 변경사항을 피하는 것이 좋습니다.

 

• 결론! 일반적으로 조회 작업에는 @Transactional(readonly=true) 를 사용하여 성능을 최적화하는 것이 좋은 방법이다.

참고 블로그: https://willseungh0.tistory.com/75      https://jaehoney.tistory.com/298      https://seungjjun.tistory.com/256

---

Next...

• 최종 프로젝트 회의 및 작성
• CS 공부
• 기술면접 대비 공부
• JPA 강의 듣기
• 알고리즘 문제 풀기 및 스터디
• 뚜까패 스터디 발표 자료 정리
• 원티드 프리온보딩 백엔드챌린지 9월 과제 수행