HTTP (HyperText Transfer Protocol)
인터넷에서 데이터를 주고받을 때의 표준
*Protocol: 표준, 약속
API의 구조
행위 / 목적지 / 수신자 / 요청 자원 / 자원의 세부 조건
행위 / 목적지 / 수신자 / 요청 자원 / 실제 자원
이런 식으로 약속된 형식으로 API를 보내줘야 함
행위와 요청 자원은 API를 보내기 전에 약속해야함
수신자는 미리 자원을 받을 준비를 해야하고
송신자는 약속된 형식으로 API를 적어야 함
그림 삽입
A 컴퓨터에서 B 컴퓨터로 요청을 보낸다고 하자
A 컴퓨터가 B 컴퓨터에게 데이터를 요청
GET /products?color=blue&limit=3&sort=price
Host: shop-api.com:5000
HTTP 요청
해당 HTTP 요청에는, GET(HTTP 메소드)와 누구에게 내놓으라 할 것인가(이 요청을 받는 컴퓨터와 프로그램 정보)가 담겨 있음
| GET(HTTP 메소드) | 클라이언트(요청하는 컴퓨터)이 서버(요청을 받는 컴퓨터)에게 데이터를 요청하는 HTTP 메서드 |
| Host: shop-api.com:5000 | HTTP 요청을 받는 컴퓨터와 프로그램 정보 *컴퓨터의 고유한 숫자(IP)와 한글로 된 이름(도메인, shop-api.com), 5000은 해당 컴퓨터에서 실행되는 여러 서비스(프로그램) 중 하나를 식별하는 포트 번호 |
| /products | HTTP 요청을 받는 컴퓨터에게 원하는 자원. Path라고도 부름 |
| ? | 구분 기호 |
| color=blue&limit=3&sort=price | 자원의 세부조건 (query) 다른 세부조건과 구분하기 위해 &를 적음 |
주세요 상품을 파란색, 3개까지만, 가격순으로
shop-api.com의 5000번 프로그램이
POST /users
Host: shop-api.com:5000
실제 사용자 정보
| POST /users | 저장하세요 /이 데이터를 |
| POST | 클라이언트(요청하는 컴퓨터)이 서버(요청을 받는 컴퓨터)에게 저장하라고 요청하는 HTTP 메서드 |
| /users | 원하는 자원 (사용자 정보) |
| Host: shop-api.com:5000 | HTTP 요청을 받는 컴퓨터와 프로그램 정보 |
| 실제 사용자 정보 | body |
Query v.s. Body
데이터를 보내는 두 가지 방법
| Query | Body |
| 데이터를 GET(주세요) 할 때 필요한 조건을 윗부분에 담아줌 GET, DELETE 메소드에서 사용됨 |
데이터를 POST(저장하세요) 할 때 아랫부분에 데이터를 담아주고 Body라 부름 POST, PUT 메소드에서 사용됨 |
Query는 GET(데이터를 달라)에서 사용되고, Body는 POST(데이터를 저장하라)에서 사용됨
| GET | 데이터를 달라 | 쿼리 |
| POST | 데이터를 저장하라 | 바디 |
| PUT | 데이터를 수정하라 | 바디 |
| DELETE | 데이터를 삭제하라 | 쿼리 |
API (Application Programming Interface)
*Interface: 정해진 규약, 규칙
Protocol v.s. Interface
| Protocol | Interface |
| 데이터 통신을 위한 규칙 | 프로그램이 상호작용하는 규칙 |
| 컴퓨터끼리 서로 통신할 때 지켜야 하는 약속 (규칙) | 프로그램(소프트웨어) 내부에서 서로 어떻게 동작할지 정하는 규칙 |
| 데이터를 어떻게 주고받을지를 정의 | 주로 객체가 모듈 간의 소통 방법을 정의 |
HTTP v.s. API
| HTTP | API |
| "통신 방식"을 정하는 프로토콜 | "무엇을 요청할 수 있는지"를 정하는 인터페이스 |
| 어떻게 데이터를 주고받을지에 대한 약속(규칙) | 특정 프로그램(소프트웨어)이 제공하는 기능(서비스)를 사용하기 위한 규칙(인터페이스) |
| "데이터를 이렇게 보내고 받아라"라고 정해놓은 통신 방법 | "이 API는 이런 기능을 제공하니까, 이렇게 요청하면 데이터를 줄게"라는 식으로 동작 |
| 요청과 응답의 형식을 정의 -> GET /users |
HTTP를 사용할 수도 있고, 다른 프로토콜을 사용할 수도 있음 -> HTTP API(REST API), WebSocket API, gRPC API 등 |
| 메소드(GET, POST, PUT, DELETE)를 사용해 클라이언트가 서버에게 원하는 행동 전달 | 서버가 제공하는 기능(리소스)에 대한 규칙을 정해놓음 -> /users 엔드포인트에서 GET 요청을 보내면 사용자 목록을 준다 |
| 데이터를 JSON, XML, HTML 등 다양한 형식으로 주고받을 수 있음 | API 문서를 보고 "이 API는 이런 기능을 제공하는구나!"를 알 수 있음 |
클라이언트가 보내는
GET /users
Host: shop-api.com
이건 HTTP 요청인거고
API는 그 요청을 수행하는 것임
클라이언트가 HTTP 프로토콜을 이용해 /users API에 요청을 보내면
서버는 API의 규칙에 따라 사용자 목록을 반환함
상품 정보를 달라고 할 때나 사용자 정보를 저장하라고 할 때,
요청을 받는 컴퓨터(서버)가 미리 상품 정보를 줄 수 있도록 준비되어 있어야 하고
요청을 받는 컴퓨터(서버)가 사요앚 정보를 저장할 수 있도록 미리 준비되어 있어야 함
이처럼 정해진 약속을 하여 특정 기능을 수행하는 것을 API라고 함
이렇게 하면 어떤 데이터를 주고, 이렇게하면 저런 데이터를 주도록 정해놓은 약속
HTTP, 즉 정해진 문법 아래서 HTTP 메소드(GET, POST 등)를 적어 정보를 주고받는데,
이때 정보를 주고받기 위해서는 서로 정해진 약속을 정해야 하고, 이 약속을 통해 특정한 기능을 수행하는데, 이 약속을 API라 부름
- HTTP는 통신 프로토콜로, 데이터를 주고받는 형식이나 문법을 정함. 예를 들면, GET, POST 같은 HTTP 메소드를 사용해서 어떻게 데이터를 요청하고 받을지 규정
- 그런데, 이 HTTP를 어떤 목적으로 사용할지, 즉 어떤 기능을 제공할지에 대한 구체적인 규칙을 API가 정의
API에서 HTTP 약속을 사용하는 것
HTTP 요청의 문법 파헤치기
GET /products?color=blue&limit=3&sort=price HTTP/1.1
Host: shop-api.com:5000
POST /users HTTP/1.1
Host: shop-api.com:5000
실제 사용자 정보
첫째줄: method path query + HTTP 버전 정보
둘째줄: 헤더(여러 줄 가능)
헤더와 실제 데이터 사이 한 줄 공백
마지막줄: 바디(여러 줄 가능. 저장/수정하고 싶은 데이터의 정보를 보내는 것)
URL (Uniform Resource Locator)
http://shop-api.com:5000/products?color=blue&limit=3&sort=price
이게 url임
어떤 사이트의 주소창
| http | 사용하고 있는 프로토콜 |
| :// | 구분 기호 |
| shop-api.com:5000 | 도메인 이름:포트 도메인 이름은 IP로 대체 가능 |
| /products | 자원의 경로(Path) |
| ? | 구분기호 |
| color=blur&limit=3&sort=price | 쿼리(추가정보) |
HTTP 응답
응답을 보내는 그림 삽입
A 컴퓨터가 보낸 HTTP 요청이 B 컴퓨터에 도착하면, B 컴퓨터는 정보를 처리하고 200 OK를 만들어 A 컴퓨터에 보냄
200 OK: 정보가 잘 저장됐어라는 뜻
B컴퓨터: 저장이라는 기능, 요청에 대한 응답을 제공(serve)한 컴퓨터: 서버
A컴퓨터: 요청을 한 컴퓨터: 클라이언트
그림그려 삽입
이 구조를 가리켜 클라이언트 서버 구조라고 함
클라이언트: 데이터 달라, 저장하라 요청
서버: 데이터 주거나 저장 후, 성공했다고 혹은 데이터를 담아 응답 반환
상태코드
우리 서버가 요청을 처리했는데 어떤 상태네요. 를 숫자로 적어줌
| 상태코드 | 뜻 |
| 200 | 정상 처리 |
| 301 | Moved Permanently 요청된 리소스의 URL이 변경되었음을 의미 |
| 404 | NotFound 요청한 것을 찾을 수 없습니다 |
| 500 | Internal Server Error 서버 내부 문제가 생겼습니다 |
HTTP 응답에는 추가 정보(바디)를 담을 수도 있음
상품 정보를 주라는 요청이 들어왔을 떄(GET), 상품 정보를 HTTP 응답 바디에 담아주는 것
200 OK
상품 정보
이렇게
HTTP 응답 역시 요청과 구조가 동일
첫째줄: 상태코드
여러줄: 헤더
한줄띄기
여러줄-바디 (추가적인 데이터를 담을 때 씀)
예시
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123
{
"name": "John Doe",
"age": 30,
"email": "john.doe@example.com"
}
'스프링부트' 카테고리의 다른 글
| [SpringBoot] Layered Architecture: Controller, Service, Repository (0) | 2025.03.08 |
|---|---|
| [DB] [Spring] Spring에서 Database 사용하기 (1) | 2025.03.05 |
| JSON 문법 (0) | 2025.03.04 |
| 서버, 네트워크의 기본 개념 (0) | 2025.02.27 |
| 스프링 프로젝트 시작하기 (1) | 2025.02.27 |