Spring 입문 주차 1일차
1. 웹 동작방식 이해하기
1)웹의 동작방식
ㄱ. IP 주소
- 거대한 네트워크망에서 각각 컴퓨터를 식별하기 위한 주소
- 네트워크 상의 데이터 송/수신의 기준이 된다.
ㄴ. 브라우저
- 웹페이지, 이미지, 비디오 등의 컨텐츠를 송/수신하고 표현해주는 소프트웨어
ㄷ. DNS(Domain Name Server)
- 일반적으로 IP주소가 아닌 www.naver.com 과 같은 도메인 이름으로 사용한다.
- 도메인 이름을 중개해주는 중개서버가 중간에 있기 때문이다.
ㄹ. HTTP
- 송/수신자가 요청/응답에 대한 규약을 정해놓은 것을 프로토콜 이라 한다.
- 웹 상에서는 HTTP라는 프로토콜을 따르고 있다.
ㅁ. API(Application Programming Interface)
- 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙
- 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각 할 수 있다.
- ex) 근무시간 기록 애플리케이션은 직원의 전체 이름과 날짜 범위를 요청하는 API를 표시하고, 이 정보가 수신되면 내부적으로 직원의 근무 시간 기록을 처리하고 해당 날짜 범위에서 근무한 시간을 반환한다.
ㅂ. Interface
- 서로 다른 두개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면
- 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미
- 컴퓨팅에서 컴퓨팅 시스템끼리 정보를 교환하는 공유 경계
ㅅ. RESTful API
- Representational State Transfer(REST)는 API 작동 방식에 조건을 부과하는 소프트웨어 아키텍처
- 대규모 고성능 통신을 안정적으로 지원 가능
- 쉽게 구현하고 수정할 수 있다
2)결론
- 서버 개발에서는 "새로운 정보"와 "기존의 정보"를 가지고 "정해진 로직"을 수행하는 것을 가장 많이 한다.
- 웹프로그래밍 동작방식, 클라이언트의 요청이 서버로 어떻게 도달하는지, 어떻게 기존 정보를 저장하는 지 알자
2. SpringBoot 및 서버 이해
1)소프트웨어 디자인 패턴
- 소프트웨어 공학의 소프트웨어 디자인에서 특정한 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계코드로 바로 전환될 수 있는 완성된 디자인은 아니지만 다른 상황에 맞게 사용할 수 있는 서술이나 템플릿이다.
ㄱ. Presentation 계층
- 사용자와 상호 작용 처리 계층
- CLI, HTTP 요청, HTML 처리 등 담당
- HTTP 요청 처리 및 HTML 렌더링에 대해 알고 있는 웹 계층
- MVC(Modle/View/Controller)가 이 계층에 속한다.
ㄴ. Domain(Business or Service) 계층
- 서비스/시스템의 핵심 로직
- 유효성 검사 및 계산을 포함하는 Business 논리 계층
- 입력/저장된 데이터를 기반으로 계산
- Presentation 계층에서 받은 데이터의 유효성(Validation) 검사
- 어떤 Data Acces를 선택할 지 결정
- 서버 프로그램이 복잡해 지면 비지니스 로직을 수행하기 위한 별도 계층이 필요
- 하지만 더 이상적으로는 유능한 서버 프레임워크로 Presentation/Data 계층이 할일이 없고 Domain 계층이 커지는거 좋음
ㄷ. Data Access(Persistence) 계층
- Database/ Message Queue/ 외부 API와의 통신 등 처리
- 데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층
ㄹ. HTTP
- 송/수신자가 요청/응답에 대한 규약을 정해놓은 것을 프로토콜 이라 한다.
- 웹 상에서는 HTTP라는 프로토콜을 따르고 있다.
2)Controller, Service, Repository
3. Database와 SQL
1)Database
- 데이터의 집합
ㄱ. 용어 정리
- DMBS(Database Management System) : 데이터베이스를 관리하고 운영하는 소프트웨어
- RDBMS(Realation DBMS) : 관계형 데이터베이스, 테이블이라는 최소 단위로 구성 ex)MySQL, PostgreSQL,Oracle Database 등이 있다.
- 인메모리 DB : 서버가 작동하는 동안에만 저장하고 멈추면 삭제 ex)H2
- MVC(Modle/View/Controller)가 이 계층에 속한다.
2)SQL
- Structured Query Language 의 약자로 RDMBS에서 사용되는 언어
ㄱ. DDL(Data Definition Language) : 테이블이나 관계의 구조를 생성하는데 사용
- CREATE : 새로운 데이터 베이스 및 테이블 생성
- ALTER : 데이터베이스와 테이블의 내용을 수정
- DROP : 데이터베이스와 테이블을 삭제, 테이블 전체를 완전히 삭제
- TRUNCATE : 데이터와 테이블을 삭제, 최초 테이블이 만들어졌던 상태( 컬럼값)만 남김
ㄴ. DCL(Data Control Language) : 데이터의 사용 권한을 관리하는데 사용
- GRANT : 사용자 또는 ROLE에 대해 권한 부여
- REVOKE : 사용자 또는 ROLE에 대해 권한 회수
ㄷ. DML(Data Manipulation Language) : 테이블에 데이터를 검색,삽입,수정,삭제하는데 사용
- INSERT: 테이블에 새로운 row추가
- SELECT : 테이블의 row를 선택
- UPDATE: 테이블의 row의 내용을 수정
- DELETE : 테이블의 row를 삭제
- JOIN : 나누어진 테이블을 하나로 합치기
4. HTTP
1)HTTP
- HTML과 같은 리소스들을 가져올 수 있도록 해주는 규약(Protocol)
- 클라이언트와 서버 모두 HTTP를 이용하여 통신하고, 개발을 하면서 Cross Origin 관련 문제를 높은 확률로 마주침
ㄱ. statefull : 서버가 클라이언트의 상태를 보존
- 대표적으로 : 한번 로그인 하면 페이지를 이동해도 로그인이 풀리지 않고 유지되는 것
- 클라이언트의 정보를 기억하는 것은 어딘가에 정보를 저장하고 통신할 때 마다 읽는 다는 뜻
- 일반적으로 브라우저의 쿠키에 저장되거나 서버의 세션 메모리에 저장되어 상태를 유지한다.
- 문제점 : 해당 서버가 멈추거나 못쓰게 됐을 때 다른 서버를 사용해야할 때 발생
- 대표적으로 : TCP의 3-way handshaking이 있다.
ㄴ. stateless : 서버가 클라이언트의 상태를 보존하지 않음
- 단순히 보내오는 요청에만 응답을 보내는 역할 수행, 상태관리는 전적으로 클라이언트 책임
- 통신에 필요한 모든 상태 정보들을 클라이언트에서 가지고 있다가 서버와 통신할 때 데이터를 실어 보내는 것
- 상태 유지에 대한 부하가 현저히 줄어 든다. 중간에 다른 서버가 이어 받아도 상관없다
- 대량의 트래픽 발생 시 서버 확장을 통해 대처를 수월하게 할 수 있다.
- 비 연결성(Connectionless) : 브라우저는 데이터를 전송할 때 마다 연결하고 응답 받은 후에 바로 끊어버린다.
- 클라이언트의 요청에 상대적으로 statefull 보다 더 많은 데이터가 소모된다. 매번 요청 시 자신의 부가 정보를 줘야함
- 대표적으로 UDP와 HTTP가 있다.
ㄷ. 토큰
- stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 JWT 토큰
- 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할 때 넘겨줌으로써 로그인이 됐음을 확인
2)HTTP 구조와 메세지
ㄱ. HTTP Message 기본 구조
- start line : 실행할 요청또는 요청 수행에 대한 성공과 실패가 들어감, 항상 첫 번째 줄에 위치
- HTTP header : 요청에 대한 설명 혹인 메세지 본문에 대한 설명
- Body : 요청과 관련된 내용이 옵션으로 들어가거나, 응답과 관련된 본문이 들어간다.
- 헤드(head) = Start Line + HTTP header // Body = pay Load 로 불린다.
ㄴ. HTTP Method
- 요청과 응답 데이터를 전송하는 방식
- 서버가 수행해야할 동작을 지정
| 메소드명 | 요청바디 유무 | 응답 바디 유무 | 서버 영향 | 기능 |
| GET | △ | ○ | X | 리소스 조회 (Read) |
| POST | ○ | ○ | ○ | 리소스 생성 (Create) |
| PUT | ○ | ○ | ○ | 리소스 수정 (Update) |
| PATCH | ○ | ○ | ○ | 리소스 수정 (Update) |
| DELETE | △ | ○ | ○ | 리소스 삭제 (Delete) |
- GET(read) : 리소스 조회, 데이터를 퀴리스팅으로 주고 받음
- POST(Create) : 리소스 생성, 요청 데이터를 바디에 담아서 전달
- PUT(update) : 기존에 데이터가 있으면 대체하고, 없으면 새로 생성
- PATCH(update) : 데이터의 일부분을 변경, 기존에 데이터 없으면 불가
- DELETE(delete) : 리소스 삭제
ㄷ. HTTP Status Code
자주 쓰이는 상태 코드들
- 200 OK : 응답 성공
- 302 Redirect : 리다이렉트 됨
- 400 Bad Request : 잘못된 요청
- 401 Unauthorized : 인증 오류
- 403 Forbidden : 접근 권한 없음
- 404 Not Found : 리소스 없음
- 405 Method Not Allowed : 요청이 허용되지 않은 메소드
- 415 Unsupported Media Type : 지원되지 않는 미디어 포맷
- 500 Internal Server Error : 서버 내부 문제
- 502 Bad Gateway : 서버 통신 장애 에러
- 503 Service Unavailable : 일시적으로 서비스 이용 불가
- 504 Gateway Timeout : 서버에서 요청을 처리하지 않고 연결을 닫음
5. Spring Controller
1)MVC(Model-View-Controller) 패턴
ㄱ. Model : 데이터의 가공을 책임진다.
- 데이터베이스, 처음에 정의하는 상수, 초기화 값, 변수 등 어플리케이션의 정보, 데이터를 나타낸다.
- 규칙1 : 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야한다.
- 규칙2 : 뷰나 컨트롤러에 대해서 어떤 정보도 알면 안된다.
- 규칙3 : 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야한다.
ㄴ. View : 사용자에게 보여지는 부분, 유저 인터페이스(User Interface)를 의미한다
- 사용자와 상호작용을 하면서 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력
- 규칙1 : 모델이 가지고 있는 정보를 따로 저장하면 안됨
- 규칙2 :다른 구성오소들을 몰라야함
- 규칙3 : 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야함
ㄷ. Controller : 브릿지, 모델과 뷰 사이를 이어주는 역할을 한다.
- 모델과 뷰 사이의 중재자 역할로 모델과 뷰에 대해 알고 있어야 한다
- 컨트롤러는 사용자가 접근한 URL에 따라 사용자의 요청사항을 파악후, 요청에 맞는 데이터를 모델에 의뢰 하고 데이터를 뷰에 반영해서 사용자에게 알려 주어야 한다.
- 규칙1 : 모델이나 뷰에 대해 알고 있어야함
- 규칙2 :모델이나 뷰의 변경을 모니터링 해야함
2)Spring MVC(Model-View-Controller)
- Spring Framework의 하위 모듈
- Model, View, Controller를 명확하게 분리해서 매우 유연하고 확장성이 좋다
5. 참조자료
1)MVC(Model-View-Controller)와 Controller, Service, Repository
Controller, Service, Repository 가 무엇일까?
찾아본 결과 Controller가 무엇인지 알기 전에 MVC 패턴에 대하여 먼저 아는 것이 중요합니다!MVC패턴은 Model-View-Controller의 약자로서 개발을 할 때 3가지 형태로 역학을 나누어 개발하는 방법론입니
velog.io