Model 데이터 디자인을 담당한다. View 실제로 렌더링되어 보이는 페이지를 담당한다. Controller 사용자의 요청을 받고, 응답을 주는 로직을 담당한다

Spring MVC

Client → DispatcherServlet 가장 앞 단에서 요청을 받아 FrontController 라고도 불림

DispatcherServlet → Controller API 를 처리해 줄 Controller 를 찾아 요청을 전달 Handler mapping 에는 API path 와 Controller 함수가 매칭되어 있음

Controller → DispathcerServlet Controller 가 Client 으로 받은 API 요청을 처리 Model 정보와 View 정보를 DispatcherServlet 으로 전달

** DispatcherServlet → Client** ViewResolver 통해 View 에 Model 을 적용 View 를 Client 에게 응답으로 전달

트러블 슈팅 해결

1. 예상과 다르게 동작 될 경우 sysout을 사용하여 찾아보기

2. Exceotion이 발생할 경우 대부분 구글에 있으니 keyword를 잘 선정하여 검색하기 (자바는 사용자가 많아 대부분 나옴 안나올 경우 keyword 다시 선정 또는 문제의 원인이 다른 곳임)

오류 줄이기

1. 설계 잘하기

• eventstorming

  eventstorming이란? http://www.msaschool.io/operation/design/design-three/

  eventstorming을 위한 보드 https://miro.com/app/dashboard/

• model -> repository -> service -> controller 순으로 개발하기

  한번에 개발하지 말고 model에서 column, 연관관계 확인하기 repository에서는 JPA가 있어서 편하지만 기능을 미리 정리하고 사용하기 service 완성 후 controller 연결해서 postman 같은 것으로 테스트 하지 말고 service를 서버단에서 먼저 테스트 하기 controller 연결하여 확인하기

2. 테스트 코드 만들기

   swagger 꼭 사용하기

트러블슈팅 꼭 기록하기

문제 발생 배경 발생한 오류의 종류, 위치, 원인 원인 파악을 위해 한 일 오류 해결방법 오류를 해결하며 배운 것

put은 리소스 전부를 바꿀 때 사용하고 patch는 리소스 일부를 바꿀 때 사용하며 만약 put을 이용하여 일부만 바꾸는 요청을 보낸다면 요청을 보낸 리소스를 제외한 다른 것은 null 값이 된다.

1. 생성자 주입 한번만 호출 되기에 의존관계가 변경되지 않을 때 사용함(대부분의 경우 변경 안함)

2. setter 주입 setter로 인하여 의존관계가 변할 수도 있음

3. 필드 주입 @Autowired 어노테이션을 이용하여 의존성 주입. 필요한 의존 객체의 타입에 해당하는 빈을 찾아서 주입해줌.

웹소켓은 클라이언트와 서버 사이에 하나의 TCP 연결을 통해 실시간으로 전이중 통신을 가능하게 하는 프로토콜이다.

전이중 통신이므로, 연속적인 데이터 전송의 신뢰성을 보장하기 위해 Handshake 과정을 진행한다. 기존의 다른 TCP 기반의 프로토콜은 TCP layer에서의 Handshake를 통해 연결을 수립하는 반면, 웹 소켓은 HTTP 요청 기반으로 Handshake 과정을 거쳐 연결을 수립한다.

REST API는 REST의 원리를 따르는 API를 의미한다.

RESTFUL이란 REST의 원리를 따르는 시스템을 의미한다.

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것이다.

스프링의 특징으로는 제어의 역전, 의존성주입, 관점지향 프로그래밍이 있다.

IoC 제어의 역전 메소드나 객체의 호출 작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다. (프레임워크가 개발자 코드를 호출한다)

DI 의존성 주입

스프링이 제공하는 의존 관계 주입 기능으로, 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 생성한 객체를 주입 시켜주는 방식이다.

AOP 관점지향 프로그래밍

핵심기능과 공통기능을 분리시켜 핵심 로직에 영향을 끼치지 않게 공통기능을 끼워 넣는 개발 방법이다.

스프링 부트 스프링은 많은 기능을 제공하기에 설정 또한 복잡하다. 그렇기에 많은 설정을 자동화를 하여 나온 것이 스프링 부트이다.

스프링과의 차이점은 스프링 부트에는 톰켓이 포함되어 있으며 starter을 통한 dependency 자동화, jar을 이용하여 배포 가능하다는 점이 있다.

starter를 통한 dependency 자동화

JPA가 필요하다면 prom.xml(메이븐)이나 build.gradle(그레이들)에 'spring-boot-starter-data-jpa'만 추가해주면 spring boot가 그에 필요한 라이브러리들을 알아서 받아온다.

http는 요청을 보내는 클라이언트와 응답을 보내는 서버가 있는 클라이언트 서버 구조로 클라이언트가 요청을 보내고 서버가 읍답을 보내면 연결을 끊으며 상태를 저장하지 않는다.

https는 http를 암호화해서 통신하는 것으로 SSL(보안 소켓 계층)과ㅏ TLS(전송 계층 보안)을 이용한다. SSL은 서버와 클라이언트와의 연결을 암호화하여 도난을 방지하고 TLS는 데이터의 무결성을 제공하여 데이터의 손상과 수정을 방지한다.

http 메소드

GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.

HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.

POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.

PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.

DELETE 메서드는 특정 리소스를 삭제합니다.

CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.

OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.

TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.

PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

CORS가 없다면 사이트를 모방하여 사용자 로그인정보를 빼오거나 다른 사람의 정보를 입력하는 등의 공격을 할 수 있다.

Simple requests인 경우 서버로 요청을 합니다. 서버의 응답이 왔을 때 브라우저가 요청한 Origin과 응답한 헤더 Access-Control-Request-Headers의 값을 비교하여 유효한 요청이라면 리소스를 응답합니다. 만약 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생합니다. Simple requests란? HTTP method가 다음 중 하나이면서

GET HEAD POST 자동으로 설정되는 헤더는 제외하고, 설정할 수 있는 다음 헤더들만 변경하면서

Accept Accept-Language Content-Language Content-Type이 다음과 같은 경우

application/x-www-form-urlencoded multipart/form-data text/plain Simple requqets라고 부릅니다. 이 요청은 추가적으로 확인하지 않고 바로 본 요청을 보냅니다.

preflight 요청일 경우 Origin헤더에 현재 요청하는 origin과, Access-Control-Request-Method헤더에 요청하는 HTTP method와 Access-Control-Request-Headers요청 시 사용할 헤더를 OPTIONS 메서드로 서버로 요청합니다. 이때 내용물은 없이 헤더만 전송합니다. 브라우저가 서버에서 응답한 헤더를 보고 유효한 요청인지 확인합니다. 만약 유효하지 않은 요청이라면 요청은 중단되고 에러가 발생합니다. 만약 유효한 요청이라면 원래 요청으로 보내려던 요청을 다시 요청하여 리소스를 응답받습니다. preflight 요청이란? Simple requests가 아닌 cross-origin요청은 모두 preflight 요청을 하게 되는데, 실제 요청을 보내는 것이 안전한지 확인하기 위해 먼저 OPTIONS 메서드를 사용하여 cross-origin HTTP 요청을 보냅니다. 이렇게 하는 이유는 사용자 데이터에 영향을 미칠 수 있는 요청이므로 사전에 확인 후 본 요청을 보냅니다.

쿠키는 클라이언트에 저장되는 키와 밸류로 이루어진 데이터로 인증 시간이 될때까지 클라이언트가 종료되어도 유지가 된다.그러나 인증 정보를 클라이언트가 가지고 있기 때문에 보안에 취약해 민감하지 않은 정보만을 저장한다.

세션은 쿠키를 기반으로 하지만 사용자 정보를 서버에 저장하고 클라이언트를 구분하기 위해 ID를 부여하고 클라이언트가 종료될때까지 유지한다. 단점은 서버에 정보를 저장하기에 사용자가 많아지면 서버에 부하가 걸린다

JWT는 제이슨 웹 토큰으로 헤더(암호화 방식), 페이로드(유저 정보), 서명 확인(헤더+페이로드+시크릿키)로 이루어져있다.따로 저장하지 않고 복호화를 통해 확인만 하면 되서 서버에 부담이 적지만 한번 발급한 JWT는 삭제할 수 없어 탈취 당할 경우 위험하다.이건 리프레쉬토큰을 이용하여 해결 할 수 있다.

ORM은 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑시켜주는 것으로 객체의 클래스와 데이터베이스의 테이블은 서로 호환성을 생각하여 만들어진게 아니기에 불일치가 존재하는데 그것을 객체 간의 관계를 바탕으로 SQL을 생성하여 해결하는 것이다.(즉 SQL을 직접 작성할 필요가 없어짐)

JPA 사용 이유는 반복적인 CRUD SQL 작성과 매핑 코드를 작성하는 것보다 간단하고 필드가 추가되거나 삭제되어도 JPA가 대신 처리해주기에 수정할 코드가 줄어드며 상속과 연관관계에 대한 불일치를 해결해준다. 그러나 통계 같은 큰데이터를 처리 할때는 JPA로 처리하기는 힘들기 때문에 직접 쿼리문을 작성하는 것이 효율을 늘릴 수 있는 방법이다.

다음으로 프레임워크의 정의는 복잡한 문제를 해결하거나 서술하는데 사용되는 기본 개념구조이다. 나는 스프링을 사용하기에 애플리케션 프레임워크에 대해 살펴보면 프로그래밍에서 특정 운영 체제를 위한 응용 프로그램 표준 구조를 구현하는 클래스와 라이브러리 모임이다. 프레임워크의 구현은 객체 지향 프로그래밍 기법이 사용되고 있는 응용 프로그램 고유의 클래스가 프레임워크의 기존 클래스를 상속할 수 있다.

프레임워크의 특징으로는 모듈화, 재사용성, 확장성, 제어의 역흐름이 있다.

라이브러리와 프레임워크의 가장 큰 차이는 제어의 역흐름에 있다.

라이브러리는 사용자의 코드가 라이브러리를 호출하여 사용되기 때문에 제어의 주도성이 사용자의 코드에 있지만 프레임워크의 경우 프레임워크가 사용자의 코드를 호출하여 사용하는 것이다. 또한 프레임워크는 라이브러리를 포함하고 있다.

프레임워크의 장점은 코드의 재사용으로 효율적이며 이미 만들어지고 감증된 코드이기에 버그 발생 가능성을 줄여준다 또한 프레임워크는 체계적으로 만들어져있기에 유지보수에 좋으며 추상화된 코드 제공을 통해 확장성이 좋다 그러나 단점으로는 다른 사람이 짠 코드이기에 코드를 습득하고 이해하는데 시간이 필요하고 기본 틀 안에서 개발을 해야하기에 제약사항이 있다는 것이다. 또한 기능이 많은만큼 프로젝트의 용량이 증가하게 된다.