[EFUB] BACK-END SEMINAR 1st SESSION

EFUB BACK-END SEMINAR 1st SESSION

서버 클라이언트 구조

서버: 서비스를 제공하는 컴퓨터. 페이지, 공유 데이터의 처리 및 저장 등의 비즈니스 로직 수행 DB와의 커뮤니케이션 수행

 

HTTP의 특성 01 : Stateful vs. Stateless

Stateful : 서버와 클라이언트 간 세션의 상태에 기반하여 클라이언트에 응답을 보내므로 세션 상태를 포함한 클라이언트와의 세션 정보를 서버에 저장

• TCP, 세션 상태에 의존적

Stateless: 클라이언트의 요청에 대한 응답만을 보내 클라이언트와의 세션 정보를 기억할 필요 X, 해당 정보를 서버에 저장 X

• HTTP, UDP / 세션 상태와 독립적
• Scaling이 자유로움: (상태를 계속 유지할 필요 X), 어떤 서버가 응답해도 상관이 없다. 클라이언트의 요청이 대폭 증가하게 되더라도 서버를 증설하는 방식을 사용할 수 있음
• 서버가 상태를 알아야 할 때 → 브라우저 쿠키나 서버 세션, 토큰 등을 사용하여 상태를 유지

 

HTTP의 특성 02: Connectionless

클라이언트와 서버가 한 번 연결을 맺은 후에 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질

• 서버에서 다수의 클라이언트와 연결을 계속 유지한다면 그만큼의 자원 낭비
• 연결을 유지하기 위한 리소스를 줄이면 그만큼 더 많은 연결을 할 수 있음 ⇒ 비연결성
• 클라이언트를 기억하고 있지 X, 동일 클라이언트와 계속 통신할 때에도 매번 새로운 연결을 시도. ⇒ 트래픽이 많고 큰 규모의 서비스를 운영할 때 한계
• KeepAlive, 쿠키와 세션 활용(4), 웹소켓 활용(5)

 

HTTP vs HTTPS

http의 약한 보안 → https가 보완
(1) SSL
(2) TLS(SSL과 거의 유사)
(3) S.E.O

 

URI/URL/URN

(1) URI(Uniform Resource Identifier)

• 인터넷 자원을 나타내는 고유 식별자 = 인터넷에 있는 자료의 ID, 유일해야함
• 웹 기술에서 사용하는 (논리적/물리적) 리소스를 식별하는 고유한 문자열 시퀀스
• URI는 URL을 포괄하는 개념

(2) URL(Uniform Resource Locator)

• 컴퓨터 네트워크 상에서 리소스의 위치를 알려주기 위한 규약
• 프로토콜 포함

(3) URN(Uniform Resource Name)

• 리소스의 이름을 나타내며, page 이후 부분까지 포함
• 프로토콜 포함 X

URI, URL 둘 다 서버에서 실제 파일 위치를 나타내는 주소 단, ID값으로 가지고 있는 자원을 식별하는 것 + 쿼리 스트링 식별자를 포함하는 것 → URI

[정리]
URI(자원 식별자) > URL(자원 위치)
둘 다 자원의 위치를 나타낸다
URI는 자원 식별 방식(식별자)를 사용해 특정 자원의 식별한다
REST API에서 인터넷 자원의 식별자를 의미하는 건 URI

자원 식별 방식

1. Path Variable(/user/{number})
2. Query Parameter(/user?id={number}&age={number})

 

API

Appplication Programming Interface
응용 프로그램에서 OS나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스(어플리케이션 - 운영체제 || 어플리케이션 - 프로그래밍 언어가 제공하는 기능 사이의 상호작용에 도움)
예시) 날씨 API, 소셜로그인 API

 

REST API

REpresentational State Transfer(REST) 형식의 API
웹상의 여러 리소스를 HTTP URI로 표현 + 해당 리소스에 대한 행위를 HTTP METHOD로 정의(HTTP URI로 정의된 리소스를 어떻게 활용할지 구조적으로 깔끔하게 표현하는 방법)

특징

1. Client-Server 구조각각 개발해야 할 내용이 명확
2. 의존성 축소
3. 클라이언트와 서버의 역할을 확실하게 구분
4. Stateless - HTTP 프로토콜의 특성
5. 작업을 위한 상태 정보를 따로 저장하고 관리 X
6. Cacheable(캐시 기능) - HTTP 프로토콜의 특성
7. 계층형 구조
8. Code On Demand(Optional), 서버로부터 스크립트를 받아 클라이언트로 실행
9. Uniform(유니폼 인터페이스), 인터페이스의 일관성
10. URI로 지정한 리소스에 대한 조작. 종속되지 않는다.

구성

1. 리소스 - URI
2. 행위 - HTTP METHOD
3. CRUD - POST GET PUT PATCH/DELETE
4. 표현 - Representation

 

HTTP METHOD

GET

리소스 조회

(클라이언트)메시지 전달 → 서버 도착 → (서버) response 전송

POST

새로운 리소스 생성할 때 사용
요청 시 바디값과 컨텐츠타입 값을 작성해 서버로 전달

PUT

리소스를 생성/업데이트 하기 위해 서버로 데이터를 보냄(서버는 응답 데이터)
아예 덮어 씌운다고 생각하면 됨. 기존에 있던 내용이 남아있지 않게 된다. 리소스를 완전히 대체한다.

PATCH

리소스를 부분 변경한다

DELETE

말 그대로 삭제

 

REST API URI 설계 주의사항

중심 규칙

1. 정보의 자원을 표현해야 한다. 리소스명은 동사보다는 명사를 사용한다
2. 자원에 대한 행위는 HTTP METHOD로 표현한다

세부 규칙

1. 슬래시 구분자(/)는 계층 관게를 나타낼 때 사용한다
2. URI 마지막 문자에는 / 를 쓰지 않는다
3. 언더바보다는 하이픈(-)을 사용한다 : 가독성이 좋지 않음
4. 대소문자를 구별하기 때문에, uri 경로에는 소문자가 적합
5. 파일 확장자는 uri에 포함하지 않고, Accept header 사용
6. 리소스 간에 연관관계가 있는 경우 ‘리소스명/리소스ID/관계있는 다른 리소스명'의 형식으로 사용

HTTP STATUS CODE

서버로 보낸 요청 상태를 나타내는 코드
서버로 보낼 작업의 수행 상태를 알려줄 수 있도록 표준에 맞춘 일종의 약속

1xx(Informational) 요청이 수신되어 처리 중, 프로세스를 계속함
2xx(Successful) 요청이 성공적이다
3xx(Redirection) 요청을 완료하려면 추가 행동 필요
4xx(Client Error) 클라이언트 오류, 잘못된 문법 등으로 서버가 요청 수행 가능
5xx(Server Error) 서버가 유효한 요청을 처리하는데 실패

201 / 202 / 203 / 204
400 / 401 / 403 / 404
500 / 502 / 503 / 504