백엔드에서 제일 중요한 것중 하나는 "프론트엔드" 와의 소통이다.
백엔드개발자가 제공하고자 하는 서버를, 클라이언트가 사용할 수 있도록, 혹은 프론트엔드개발자와 협업할 수 있도록 API 가이드를 작성하고 서로 주고 받을 데이터의 룰을 정한다.
오늘은 가장 기본이 되는 개념인 REST API와 HTTP에 대한 개념을 공부해보았다.
✅ Study To-do
- REST, REST API, RESTful
- HTTP 통신
- 브라우저에 URL 입력 후 요청하여 서버에서 응답하는 과정
REST란?
Representational State Transfer
소프트웨어 “아키텍쳐 스타일”
- 인터넷과 같은 복잡한 ‘네트워크 통신’을 관리하기 위한 제약 조건을 정의 (프로토콜 같은 느낌)
- 대규모 고성능 통신을 안정적으로 사용할 수 있게 함
- 자원을 이름(*URI)으로 구분하고, HTTP 표준을 사용함
*URI : Uniform Resource Identifier (인터넷 상의 “자원주소”, 자원을 식별하는 표준 규약의 문자열) URL 과 URN을 모두 포함하는 것이 URI
https://www.example.com/index.html
(프로토콜)://(호스트)/(경로)REST의 6가지 제약 조건
- 클라이언트-서버 : 클라이언트는 잘 정의된 인터페이스로 “서버와 분리”
- 무상태 : 서버가 이전의 모든 요청과 “독립적으로” 모든 클라이언트 요청을 완료
- 캐시 : 응답을 자체 캐시에 저장 (인증 빨리 할수 있게 하는 등)
- 균일한 인터페이스 : 아키텍처 단순화, 분리, 독립
- 계층 시스템 : 클라이언트는 최종 서버에 직접 연결되었는지, 중개자(Foreign Address 등)에 연결되었는지 알 수 없음 (Abstraction)
- 주문형 코드 : 서버는 가상 머신 내에서 실행될 수 있는 논리(코드)를 클라이언트로 전송하여 클라이언트의 기능을 일시적으로 확장하거나 정의할 수 있음 (ex. 브라우저로 JavaScript를 보내서 새로운 기능을 임시 생성, 확장 하는 등)
API 란?
Application Programming Interface
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의하는 것
RESTful이란?
REST 원칙을 지켜서 만든 서비스의 상태를 표현하는 말
RESTful API는 REST의 설계 원칙을 잘 따르는 API라는 의미
RESTful 하다 =
- URI는 리소스만 표현
- HTTP 메서드 (GET, POST, PUT, DELETE 등) 로 동작을 구분,
- 무상태성을 유지,
- 일관된 UIR구조와 표현을 사용
⇒ 최종적으로 REST 아키텍처 스타일을 충실히 따르는 것.
REST API 동작
- 클라이언트(FE 등)가 서버에 요청 (API 문서에 맞게 서버가 이해하는 방식으로 요청)
- 서버가 클라이언트를 인증(토큰)하고 해당 요청을 수행할 수 있는 권한이 있는지 클라이언트를 확인
- 서버가 요청을 수신하고 내부적으로 처리
- 서버가 클라이언트에게 응답을 반환, 요청 성공 여부와 요청한 정보를 포함
REST API 구성요소
- 고유 리소스 식별자
(REST는 일반적으로 URL 로 식별) - 메서드
HTTP 메서드는 리소스를 수행해야 하는 작업을 서버에 전달
- GET : 클라이언트가 서버의 지정된 URL에 있는 리소스에 액세스
API 요청에 파라미터를 넣어, 데이터를 필터링하도록 서버에 지시 가능
- POST : 클라이언트가 서버에 데이터를 전송
- PUT : 서버의 기존 리소스를 업데이트하도록 함
- DELETE : 리소스를 제거, 서버의 상태 변경 가능 - HTTP 헤더 (부가정보)
요청 및 응답의 형식을 나타내고, 요청 상태등에 대한 정보 제공
- 파라미터
- 경로파라미터 : URL의 경로 지정
- 쿼리파라미터 : 리소스에 대한 추가 정보 요청
- 쿠키파라미터 : 빠른 인증을 위함 - 본문 (본 데이터)
HTTP
웹(인터넷)에서 브라우저(클라이언트)와 서버간에 데이터를 주고받기 위한 프로토콜.
요청(Request)와 응답(Response)로 이루어짐.
[클라이언트 Request 메시지 구조]
- Request Line :
메서드 + URL + HTTP ver (여기서 URL이 요청시의 target resouce 주소. 정확히 말하면 경로임. host서버 주소/ 뒤의 경로)
https://(호스트서버주소)/(리소스 경로 URL)
https://api.example.com/users/resouce1- Header :
응답에 대한 부가정보 (메타데이터) : Content-type (데이터 형식), Content-Length, Set-Cookie, Authorization (인증 토큰) 등
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...- 공백라인 (헤더, 바디 구분용)
- Body :
실제로 서버에 전달되는 데이터
{
"username": "hong",
"password": "1234"
}[서버 Response 메시지 구조]
- Status Line : HTTP ver + Status code + status message
HTTP/1.1 200 OK- Header : (요청과 동일)
- 공백라인 : (요청과 동일)
- Body : (요청과 동일)
[상태 코드]
서버가 클라이언트의 요청을 어떻게 처리했는지를 알려주는 코드.
- 1xx (정보): 요청을 받았고 처리 중
- 2xx (성공): 요청 성공
- 200 OK
- 201 Created
- 3xx (리다이렉션): 요청한 리소스의 위치 변경
- 301 Moved Permanently
- 302 Found
- 4xx (클라이언트 오류): 잘못된 요청
- 400 Bad Request
- 401 Unauthorized
- 404 Not Found
- 5xx (서버 오류): 서버가 요청 처리 실패
- 500 Internal Server Error
- 502 Bad Gateway
브라우저 URL 입력, 서버 요청, 서버 응답의 일련과정
- 사용자가 브라우저 주소창에 URL 입력
https://www.example.com/users/1
https://(만든 서버의 주소)/(리소스 경로)-
브라우저에서 URL 파싱 및 DNS 조회, TCP Handshake
- 프로토콜 https + 호스트(서버주소) www.example.com + 경로 /users/1 + 포트 443 (HTTP기본)
- DNS 조회 (www.example.com)의 IP주소를 얻기 위해
- TCP 연결 (SYN → SYN-ACK → ACK) : 3way handshake
-
HTTP 요청 메세지 생성
요청라인, 헤더, 본문 까지 HTTP 요청메세지 format에 맞게 메세지 생성 후 서버 전송 -
서버측에서 HTTP 포트로 요청 수신
- 정적 파일 요청일 시 직접 자동응답
- 동적 요청일 시, 백엔드 애플리케이션 서버에서 처리 (Spring Boot 등)
- 1) 라우터가 해당 요청을 설정한 “컨트롤러”에 연결
- 2) URI 경로를 Path Variable로 추출 (필요 시, 쿼리 파라미터, 헤더, 쿠키 등 추가 확인)
- 3) DB 접근 : UserRepository 내에서 SQL등으로 데이터 조회
- 4) 응답데이터 생성
-
HTTP 응답 전송
-
클라이언트 측 (FE)에서 응답 메세지 parsing
[출처]
