10/04 백엔드 스터디 정리

목차

1. HTTP + CRUD

2. REST API

3. Java

 

HTTP + CRUD

HyperText Transfer Protocol

 

클라이언트와 서버 간의 통신 규약으로 하이퍼 미디어 문서를 주고 받을 수 있는 프로토콜

• TCP/IP & UDP 프로토콜을 사용
• 80번 포트를 사용
• HTTPS의 경우 443 포트를 사용

 

Request를 통해 URL, Header, Body로 서버에 정보 혹은 데이터 요청/전송

 

Response를 통해 바디에 데이터를 전송

 

Stateless Protocol

무상태 프로토콜

 

서버간 두 요청 간에 어떠한 데이터도 유지하지 않음

 

모든 요청이 상호 독립적

 

쿠키, 세션, 토큰 등으로 이를 극복

 

 

HTTP Message

 

구성 ->

• Request Line ex) GET/docs/index.html HTTP/1.1
• Status Line ex) HTTP/1.1 200 OK
• Request/ Response Header ex) Host, Accept, Content-Type, Data etc...
• Request/ Response Body ex) {"username"="Park"}

 

HTTP Method

HTTP Method	Action	RequstBody
GET	조회	X
POST	생성	O
PUT	수정	O
DELETE	삭제	X

 

 

HTTP Status Code

응답 코드 범위	표시 상태
2xx	성공 상태
3xx	리다이렉션을 알리는 상태
4xx	요청 오류
5xx	서버 내부 오류

 

 

CRUD

Create, Read, Update, Delete

-> 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능

CRUD	Action	HTTP Method	SQL
Create	생성	POST	INSERT
Read	조회	GET	SELECT
Update	수정	PUT	UPDATE
Delete	삭제	DELETE	DELETE

 

 

REST API

URI

-> Uniform Resource Identifier

통합 자원 식별자(자원을 나타내는 주소), 고유하게 정보 리소스를 식별하고 위치를 저장

 

URL

-> Uniform Resource Locator

통합 자원 지시자, 특정 서버의 한 리소스에 대한 구체적인 위치 서술

 

URI는 URL을 포함한 개념

 

네이밍이 직관적이어야 하고, 명사가 이해하기 좋음, 항상 일관된 규칙으로 작성해야함

 

 

REST API

-> Representational State Transfer API

 

로이 필딩은 HTTP의 주요 저자 중 한 사람으로, 웹의 장점을 극대화하는 아키텍처 REST를 발표

 

API

-> Application Programming 

 

URI는 서버 설계 도면 /  API는 서버 사용 설명서

 

URI는 서버 구성 요소를 나타냄

 

URI와 API 둘 다 명확하고 직관적이어야 사용하는 사람이 헷갈리지 않음

 

 

REST

 

리소스 지향 아키텍처 -> 모든 것을 리소스, 명사로 표현함

 

가급적이면 리소스 기반의 명사로 정의하는 것이 REST 형태의 디자인

 

 

REST API 중심 규칙

 

1. 자원(Resource) ==> URI는 정보의 자원을 표현한다.

 

2. 행위(Verb) ==> 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

 

 

REST API 중심 사항

 

1. 슬래시 구분자(/)는 계층관계를 나타내는데 사용한다. 디렉토리 느낌

 

2. URI 마지막 문자로 슬래시를 포함하지 않는다.

 

3. 하이픈(-)은 URI 가독성을 높이는데 사용한다.

 

4. 밑줄(_)은 URI에 사용하지 않는다.

 

5. URI 경로에는 소문자가 적합하다.

 

6. 파일 확장자는 URI에 포함시키지 않는다.

 

7. REST 리소스 간에 연관관계가 있는 경우 

-> /리소스명/리소스ID/관계가 있는 다른 리소스

 

 

REST API 특징

 

Uniform Interface

-> URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키택처 스타일

 

Stateless

-> HTTP Session과 같은 컨텍스트 저장소에 상태정보를 저장하지 않음

-> API 서버는 들어오는 요청만을 들어오는 메세지로만 처리하면 되며, 세션과 같은 정보를 신경 쓸 필요X

 

Layeres System(계층형 구조)

-> REST 서버는 다중 계층으로 구성될 수 있음

-> 보안, 로드벨런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있음

-> PROXY, 게이트웨이 같은 네트워크 기반의 중간 메체를 사용할 수 있음

 

Self - descriptiveness(자체 표현 구조)

-> REST API 메세지만 보고도 API를 쉽게 이해할 수 있는 구조

 

Client-Server

-> REST 서버는 API를 제공하고, 그 API를 통해서 비즈니스 로직 처리 및 저장을 책임짐

-> 각각의 역할이 확실히 구분되지 때문에 클라이언트 / 서버가 각자 개발해야할 내용이 명확

-> 서로 간의 의존성이 줄어듬

 

Cachable

-> HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에 캐싱 적용 가능 ex) RabbitMQ, Radis

-> Last-Modified, E-tag 등을 이용해서 구현

 

 

API 명세서

 

API 문서는 누가 봐도 이해할 수 있도록 명확하고 직관적이어야한다.

 

즉, 내부적으로 어떻게 구현되어 있는지 몰라도 서비스를 사용할 수 있어야 한다.

 

클라이언트에 API 명세서를 제공해야 서버의 API를 사용할 수 있다.

 

대표적으로 swagger, postman api 등이 있고 노션과 깃헙 위키가 가장 허들이 낮다.

 

 

API 명세서 구성 요소

• API 이름
• HTTP Method
• Content-Type
• 요청 헤더/ 바디/ params/ query
• 응답 바디

 

 

인증 Authentication 

 

사용자가 자신이 주장하는 바로 사용자가 맞는지 확인하는 절차

 

 

인가 Authorization

 

사용자가 특정 자원에 대해 접근 권한이 있는지 확인하는 절차

-> 클라이언트가 주장하는 사용자가 맞는지 확인

 

 

인증 방법

 

1. 쿠키

-> 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일

• 단순한 키-벨류쌍 -> 클라이언트 로컬에 저장
• 일정 시간동안 저장할 수 있음
• 서버로부터 쿠키가 오면 웹 브라우저는 쿠키를 저장했다가 요청시 브라우저가 자동으로 쿠키를 같이 보냄
• 쿠키는 요청과 응답의 헤더에 저장됨
• 모바일 앱에서는 쿠키 활용이 아주 제한적 - 거의 불가능

 

2. 세션

-> 일정 시간 동안 같은 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지하는 기술

• 웹 브라우저를 통해 웹 서버에 접속한 이후로 브라우저를 종료할 때 유지되는 상태
• 클라이언트는 발급받은 세션 ID를 서버 메모리에 저장
• 서버가 재시작되면 (메모리 리셋), 세션 데이터가 사라짐
• 넷플릭스 / 인스타그램처럼 하나의 사용자가 여러 로그인 정보를 가지는 경우 유요
• 세션은 서버의 자원을 사용하기 때문에, 무분별하게 만들다 보면 서버의 메모리에 영향을 줘 속도가 느려질 수 있음

 

3. 토큰

-> 로그인이 통과되면 엑세스 토큰을 발급받아 클라이언트에서 사용하는 방법

 

보안성: 정보가 담긴 데이터(JSON 객체)를 암호화

 

Self-Contained: JWT 자체적으로 필요한 모든 정보를 포함함

 

확장성: 인증 저장소(ex)세션, 디비 등)가 필요하지 않음

 

 

3-1. JWT(Json Web Token)

-> 두 개체 사이에서 JSON 객체를 사용하여 정보를 안전하게 전달

 

헤더: JWT 토큰의 유형 / 사용된 해시 알고리즘

 

페이로드: 클라이언트에 대한 정보

 

시그니처: 서명 정보

 

 

Java

객체지향 프로그래밍 언어

-> 객체들이 서로 메세지를 통해 협력하는 패러다임

-> 객체지향은 캡슐화를 통해 변경을 최소화로 하여 의존성 관리를 통해 독립적인 개발을 가능하도록 하는 것이 핵심

 

 

SOLID 원칙

 

1. SRP: 단일 책임 원칙

-> 각 클래스 혹은 인터페이스는 하나의 책임만 가져야 한다.

 

2. OCP: 개방 - 폐쇄 원칙

-> 확장엔 개방적이지만 변경엔 폐쇄적이어야 한다.

 

3. LSP: 리스코프 치환 원칙

-> 부모 클래스에서 자식 클래스로 치환했을 때 부모 클래스의 역할을 자식 클래스가 완벽히 수행해야 한다.

 

4. ISP: 인터페이스 분리 원칙

-> 객체는 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.

 

5. DIP: 의존성 역전 원칙

-> 객체는 구현체보다 추상체에 의존해야 한다.