잡동사니

REST API란 뭘까? 많이 들어는 봤는데 개념이 모호하다.지금부터 이에 대해 간단히 알아보자. 시작하기 전 이 글은 진정한 의미의 REST API가 아닌 개발자들이 일반적으로 알고 쓰는 수준의 REST API 이다.REST API는 정보들이 주고받아지는 데 있어서

빈 스코프 공부를 하면서 제일 어려웠던 부분을 다시 정리해보았다.웹 스코프를 이용한 예제를 개발해보자.동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다.이럴때 사용하기 딱 좋은것이 바로 request 스코프이다.다음과 같이 로그가 남도

다음과 같은 상황을 가정해보자.피자 셰프가 레시피를 봐야만 피자를 만들 수 있다. 요리사는 레시피가 변경되면 새로운 피자를 만들게 된다. 따라서, 요리사는 레시피에 의존하는 관계라 할 수 있다.이를 간단히 코드로 살펴보자.PizzaChef 객체는 PizzaRecipe

검증1의 ValidationItemControllerV1에서 검증 오류 발생시 기존 데이터가 보존되는 원리를 자세히 알아보자.컨트롤러 구현부를 보자.ValidationItemControllerV1의 일부분addForm() 메소드를 보면 모델에 Item 빈 객체를 넣어주

서블릿이 제공하는 HttpSession을 이용하여 로그인을 처리했다.일단, 세션의 동작 방식을 간단히 복습해보자.클라이언트가 서버로부터 로그인 요청을 한다.서버는 요청 로그인 id값마다 고유의 sessionId값을 만들어 세션 저장소에 저장한다.세션 저장소 : Map

웹 브라우저에서 서버가 요청을 받고 응답을 보내는 과정 중 컨트롤러에서 예외가 발생했다. 이러한 경우 서블릿에서 예외가 어떻게 처리되는지 알아보자. Filter 코드를 보자. 이 코드를 보면, 마치 필터의 try-catch 문에서 예외를 처리하는 것 처럼 보인다.

WAS와 웹서버의 개념을 정리해보았다. 간단히 알아보자.일단 서버의 개념을 짚고가자. 서버는 컴퓨터라고 생각하자.같은 컴퓨터도 서비스를 해주느냐 제공받느냐에 따라 서버와 클라이언트로 나뉜다.서버는 다른 의미로도 사용이 되는데 어떤 컴퓨터로 하여금 서버 역할을 하도록 해

지금까지 스프링의 MVC에 대해 자세히 공부를 했었다. 그러나 MVC의 기본적인 개념들이 모호하여 정리해보았다.간단한 사이트를 정적 웹으로 구현한다고 하면 어떨까? 이는 별 문제가 없을 것이다.그러나 대규모의 사이트(네이버나 구글)들을 정적 웹으로만 구현하라고 하면 어

기존 필터와 인터셉터의 개념이 좀 모호했는데 좀 자세히 정리해보았다. 필터 필터(Filter)는 J2EE 표준 스펙 기능으로 디스패처 서블릿(Dispatcher Servlet)에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있

DB를 연동하여 프로젝트를 할 때 테스트 용 SQL을 작성하여 서버 실행마다 DB에 샘플 데이터를 저장하고 싶으면 어떻게 할까? 일일히 서버를 실행하고 작성한 SQL을 실행하는 것은 매우 번거로울 것이다.먼저 application.properties 에 다음을 추가하자

다른 엔티티와 일대다 관계를 가진 엔티티를 조회하는 과정에서 다음 문제가 발생했다. 구글링을 해보니 지연로딩으로 인해 연관관계를 가지고 있는 엔티티가 제때 호출이 안된 것이였다. 조회하려는 엔티티와 이와 연관관계를 맺고 있는 엔티티는 다음과 같다.Owner 와 일대다

컨트롤러에서 요청 메시지 바디에 있는 정보를 통해 엔티티 컬럼을 추가하는 과정에서 다음 오류가 발생했다.컨트롤러에서 호출된 메소드와 요청 메시지 바디에 담긴 정보는 다음과 같다.여기서 사용되는 엔티티들은 다음과 같다.Owner 엔티티와 다대일 관계이다.FK를 가진다.S

APM(Application Performace Monitoring)을 통해 프로젝트 부하 테스트를 진행하던 중 병목 현상이 발생했다. 초당 100건의 요청을 보낸 결과 (실전에서 본인이 맡은 부분이 이러면 똥줄 탄다고 한다.)빨간색 : 실패파란색 : 성공현재 WAS와

지난 우아한테크코스 6기 프리코스를 진행하면서 Getter를 지양하는 것을 항상 목표로 삼았다. 물론, 도메인을 조회를 하는 경우 Getter는 가히 필수적이다. 그럼 어떤 상황에서 Getter를 지양해야 될까? 더 나아가 왜 사용하면 안될까? (사용하면 진짜 편하던

Value Object(값 객체, 이하 VO) 객체에 대해 알아보자. 내가 생각하는 VO 도입 이유와 장점을 서술해보려 한다.VO는 단어 그대로 값을 저장하는 객체이다. 특정 또는 여러 도메인의 값을 나타내는 역할이다.자동차 경주를 생각해보자. Car 객체는 크게 이름

Spring Boot를 통해 프로젝트를 진행한다면 계층 간 데이터 전달 시 DTO 클래스 사용은 필수다. 그러나 이를 왜 사용하는지, 사용한다면 어떤 장점이 있는지에 대해 놓치고 있는 것 같아 자세히 정리해보려 한다.추가로, Spring Boot에서 사용하는 5 Lay

DB에서 자주 조회해야 하는 데이터가 있다고 생각해보자. 매 요청마다 해당 데이터를 DB에서 가져가 준다면 엄청난 성능 저하가 발생할 것이다. 만약, 게임 사이트 메인 페이지에서 레벨이 높은 100명의 유저 정보를 보여준다고 생각해보자. 유저 정보는 변동성이 상대적으로

결제 관련 데이터를 받는 상황을 생각해보자. 결제 수단은 아래와 같다. 신용카드 계좌 이체 간편 결제 상품권 값을 4가지로 제한되므로 아래 열게체를 활용하여 요청을 받을 수 있다. public class PaymentController { @PostMappi

시작하기 전 QueryDSL의 경우 버전별 문법 차이가 존재합니다. 아래 QueryDSL 버전은 Querydsl-JPA 4.2.1 입니다. > 버전이 5.X라면 아래 내용과 상이할 수 있습니다. 1. extends / implements 사용하지 않기 > JPAQu

최근 프로젝트에서 소셜 로그인 구현을 맡게되어 관련 코드를 공유하고자 합니다. 일단 소셜 로그인의 경우 다음 3가지를 고려했습니다.네이버카카오구글과정은 아래와 같습니다.소셜로 부터 인가 코드 받아오기인가 코드를 통해 소셜 토큰 받아오기소셜 토큰을 통해 소셜에 등록된 사

객체지향 패러다임은 객체마다 적절한 책임과 역할을 부여하여 객체간 협력을 통해 문제를 해결해나가는 프로그래밍 기법이다.이 협력 과정에서 객체는 클라이언트, 서버 둘 중 하나를 담당하게 된다. 아래 예시를 통해 알아보자.Movie.caculateMovieFee() 메서드

카카오톡 선물하기 클론 + 펀딩 프로젝트에서 결제 기능을 담당하게 되었다. 결제 수단은 카카오페이다.프론트엔드가 백엔드에게 결제 준비 요청을 보낸다.백엔드는 요청값 일부를 캐싱 후 카카오페이 서버에 결제 준비(https://developers.kakaopay.