✅ HTTP (HyperText Transfer Protocol)
HTTP 메시지에는 모든 것을 전송
-> HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터를 전송
HTTP의 역사
HTTP/0.9 (1991년) : GET 메서드만 지원, HTTP 헤더 X
HTTP/1.0 (1996년) : 메서드, 헤더 추가
HTTP/1.1 (1997년) : 가장 많이사용하며, 가장 중요한 버전임
-> RFC2068(1997), RFC2616(1999), RFC7230~7235(2014)
HTTP/2 (2015) : 성능개선
HTTP/3 (진행중) : TCP 대신에 UDP 사용, 성능 개선
✅ HTTP 메시지 구조
요청 메시지 시작라인 :
HTTP메소드
요청대상
HTTP버전
- 응답 메시지 시작라인 :
HTTP버전
HTTP 상태 코드
-> 200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류- HTTP 헤더
-> HTTP 전송에 필요한 모든 부가정보
-> 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보 등등- HTTP 메시지 바디
-> 실제 전송할 데이터
-> HTML 문서, 이미지, 영상 JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
✅ 무상태 (Stateless
)
장점 : 서버 확장성 높음(스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송
💡 주로 Stateless
를 사용하며 상태 유지는 최소한 만으로 사용해야한다.
✅ 상태유지 (Stateful)
✅ 비 연결성
✅ 비연결성의 한계와 극복
✅ API URI 잘 작성하는 방법
리소스
를 잘 식별하기리소스
와 해당 리소스를 대상으로 하는 행위
를 분리행위
: 메서드 (HTTP 메소드) -> GET, POST✅ 주요 HTTP 메서드
GET
: 리소스 조회GET /members/100 HTTP/1.1
Host:localhost:8080
/members/100
{
"username" : "young",
"age":20
}
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34
{
"username" : "young",
"age":20
}
POST
: 요청 데이터 처리, 주로 등록에 사용메시지 바디
를 통해 서버로 요청 데이터 전달사용자 등록
에 어울림POST /members HTTP/1.1
Content-Type: application/json
{
"username" : "young",
"age":20
}
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100
{
"username" : "young",
"age":20
}
PUT
: 리소스를 완전히 대체, 해당 리소스가없으면 생성 (파일복사 개념임)사용자 프로필 변경
이나 파일등록
에 어울림 => 있으면 대체, 없으면 생성/members/100
age : 100
userName : '홍길동'
위와 같이 /members/100 에 이미 값이 존재하는 상태에서
age 필드값을 "50"을 바꾸면
기존에 있던 값들은 다 없어지고, age:50만 남아있음 (완전히 대체됨)
/members/100
age : 50
PATCH
: 리소스 부분 변경/members/100
age : 100
userName : '홍길동'
동일한 방법으로 /members/100 에 이미 값이 존재하는 상태에서
age 필드값을 "50"을 바꾸면
값들이 유지된 상태로 age 부분만 값이 바뀜
/members/100
age : 50
userName : '홍길동'
DELETE
: 리소스 삭제구분 | DELETE | POST |
---|---|---|
표준 동작 | HTTP 메서드 설계 원칙을 따름 | REST 원칙을 벗어날 수 있음 |
목적 | 리소스 삭제 | 작업 트리거 또는 삭제 요청 처리 |
Idempotent | 예 (같은 요청 반복 → 동일한 결과) | 아니요 (반복 시 다른 결과 가능) |
요청 본문 사용 | 일반적으로 사용하지 않음 | 추가 데이터를 포함 가능 |
사용 상황 | 단순한 리소스 삭제에 적합 | 복잡한 삭제 조건/정보가 필요한 경우 |
RESTful 적합성 | RESTful 원칙에 부합 | 비표준적이거나 필요에 따라 예외적 사용 |
DELETE
: 단순하고 명확한 리소스 삭제 작업에 적합하며, RESTful API 설계 원칙에 부합.POST
: 추가 정보가 필요한 복잡한 삭제 작업이나 비표준적 요구사항이 있을 때 사용.✅ HTTP 메소드의 속성
Safe
: 안전을 의미하며 호출해도 리소스를 변경하지 않는 것 ex) Get 메소드Idempotent
: 멱등을 의미하며 여러번 호출해도 결과가 똑같은 것Casheable
: 캐시가능을 의미하며✅ HTTP API 데이터 전송
application/json
을 주로 사용 (표준)HTTP API를 설계할 때는 최대한 리소스를 낭비를 줄이는 선에서 API를 개발하고
제약이 있을 경우 컨트롤 URI
를 사용해서 설계해야함
EX) 컨트롤 URI 란 POST로 예시를 들면 /new /edit /delete 가 있음
✅ HTTP 상태코드