| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- redis
- 서블릿 컨테이너
- AWS
- DI
- @Transactional
- JPQL
- dockerhub
- CORS
- JdbcTemplate
- Web
- Spring Data JPA
- Spring Container
- 페이징
- JPA
- kafka
- 지연 로딩
- docker compose
- @ComponentScan
- 컨테이너
- Dead Letter Queue
- mybatis
- Spring
- MSA
- DLQ
- docker
- JWT
- 스프링 부트
- Routing Key
- securitycontextholderfilter
- 쿠버네티스
- Today
- Total
look-forest
HTTP 메서드 활용 본문
이번 시간에는,
실무에서 앞서 배운 HTTP 메서드를 어떻게 적용하면 좋을지 정리해보겠다.
클라이언트에서 서버로의 데이터 전송 방식
데이터 전달 방식은 크게 2가지
- 쿼리 파라미터를 통한 데이터 전송
GET / 주로 필터(검색어, 정렬 조건) - 메시지 바디를 통한 데이터 전송
POST, PUT, PATCH / 회원 가입, 주문, 리소스 등록, 리소스 변경
데이터 전송의 4가지 CASE
| 정적 데이터 조회 | 응답 결과를 보통 정적리소스, HTML로 받을 때 사용 |
| 동적 데이터 조회 | 응답 결과를 보통 HTML로 받을 때 사용 |
| HTML Form을 통한 데이터 전송 | 응답 결과를 보통 HTML로 받을 때 사용 |
| HTTP API를 통한 데이터 전송 | 응답 결과로 HTML이 아닌 데이터를 전달 받음 |
쿼리 파라미터 데이터 전송
1. 정적 데이터 조회 - 쿼리 파라미터 미사용
2. 동적 데이터 조회 - 쿼리 파라미터 사용

메세지 바디 데이터 전송 : Form, API
HTML Form 데이터 전송
웹 브라우저가 HTTP 메시지를 생성 시,
Form => POST(메세지 바디), GET(쿼리파라미터)
1) POST

Content-Type: application/x-www-form-urlencoded 사용 (default)
- Form의 내용을 메시지 바디를 통해 전송 (쿼리 파라미터 형식, key=value)
- 전송 데이터를 url encoding 처리
예) abc김 → abc%EA%B9%80
2) GET

마찬가지로 HTTP 메시지를 생성하되,
메시지 바디가 아닌 start-line에 쿼리 파라미터로 데이터 전송
3) Content-Type: multipart/form-data
파일 업로드 같은 바이너리 데이터 전송 시 사용
다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)

HTTP API 데이터 전송
HTTP API는 HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고받으며 통신하는 것
- 언제 사용하는가?
- HTML이 없는 경우 ▷ 브라우저가 아닌, 서버끼리 통신, 앱 클라이언트와 통신
→ HTTP API로 데이터를 전송한다.
- HTML에서의 Form 전송 대신 javascript를 통해 통신(AJAX)
웹 클라이언트(react, vue)와 API 통신을 하기도 한다.
(AJAX는 HTML을 받아서 리로드 하는 게 아니었다. json 데이터만 받았다.) - HTTP API는 브라우저, HTML 없이 HTTP 메시지로 통신한다
1) 브라우저가 HTTP 메시지 만들어주는 게 아니라 직접 만든다
2) 응답 결과로 HTML이 아닌 데이터를 전달받는다 - Content-Type: application/json을 주로 사용

※ HTTP API와 REST API
HTTP API와 REST API는 사실상 거의 같은 의미로 사용된다.
그런데 디테일하게 들어가면 차이가 있다.
HTTP API는 상당히 넓은 의미로, 'HTTP를 사용해서 서로 정해둔 스펙으로 통신하는 것'이다.
반면에 REST API는 HTTP API에 다음 4가지 제약 조건이 추가된다.
- 자원의 식별
- 메시지를 통한 리소스 조작
- 자기 서술적 메서지
- 애플리케이션의 상태에 대한 엔진으로써 하이퍼미디어
(HTML처럼 하이퍼링크가 추가되어 다음에 어떤 API를 호출해야 하는지 해당 링크를 통해서 받을 수 있어야 함)
그런데 통상 해당 조건을 지키지 않아도 REST API라고 하기 때문에, HTTP API나 REST API를 거의 같은 의미로 사용하고 있다.
참고로 이런 부분을 완벽하게 지키면서 개발하는 것을 RESTful API라고 한다.
(실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고, 또 추가 개발 비용 대비 효과가 있는 것도 아니다)
[결론]
다들 HTTP API를 REST API라고 하고 있기 때문에,
누군가 REST API라고 하면 그냥 '아~ HTTP API를 이야기하는구나'하고 생각하면 된다. (물론 엄격하게는 다르다)
HTTP method와 URI 설계 예시
1. POST, PUT, PATCH
Q. 리소스 수정 시, POST / PUT / PATCH 중 무엇을 선택해야 할까?
- PATCH: 서버에 일부 데이터만 보내 부분 수정할 때
- PUT: 서버에 전체 데이터를 다 보낼 때 (기존 데이터를 삭제하고 덮어쓰기 때문)
- POST: 애매하면 POST를 쓰자
2. 컬렉션/스토어
URI를 누가 정하느냐에 따라 POST/PUT 결정
Q. 리소스 등록 시, POST를 쓸까? PUT을 쓸까?
- 클라이언트가 등록될 리소스의 URI를 모를 경우 → POST (컬렉션)
- 클라이언트가 직접 리소스의 URI를 지정할 경우 → PUT (스토어)
POST의 신규 자원 등록 시 특징
예) 회원 관리 시스템
1) 클라이언트는 등록될 리소스의 URI를 모른다
▷ POST /members
2) 서버가 새로 등록된 리소스의 URI를 생성해준다
▷ HTTP/1.1 201 Created
Location: /members/100
이처럼, 서버가 리소스의 URI를 생성하고 관리하는 디렉터리를 컬렉션(Collection)이라고 한다
(여기서 컬렉션은 /members)
PUT의 신규 자원 등록 시 특징
예) 파일 등록 시스템 (덮어씀)
1) 클라이언트가 리소스의 URI를 알고 있어야 한다
▷ PUT /files/start.jpg
2) 클라이언트가 직접 리소스의 URI를 지정한다
이처럼, 클라이언트가 리소스의 URI를 알고 관리하는 디렉터리를 스토어(Store)라고 한다
(여기서 스토어는 /files)
3. 컨트롤 URI
HTTP 메서드로 해결하기 애매한 경우에 사용한다 (HTTP API 포함)
예를 들어,
HTML FORM 사용할 경우, GET, POST만 지원하므로 제약이 있다.
POST 밖에 못 쓰는데 회원 등록, 수정, 삭제를 어떻게 구분할 것인가?
| 기능 | URI | HTTP Method |
| 회원 등록 | /members | POST |
| 회원 수정 | /members/{id} | POST |
| 회원 삭제 | /members/{id} | POST |
동사로 된 리소스 경로를 사용할 수 밖에 없다(컨트롤 URI)
| 기능 | URI | HTTP Method |
| 회원 등록 | /members/new | POST |
| 회원 수정 | /members/{id}/edit | POST |
| 회원 삭제 | /members/{id}/delete | POST |
(POST의 /new, /edit, /delete가 컨트롤 URI)
※ 참고하면 좋은 URI 설계 개념
• 문서(document)
단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
예) /members/100, /files/star.jpg
• 컬렉션(collection)
서버가 관리하는 리소스 디렉터리
서버가 리소스 URI 결정
POST 기반 등록
예) /members (컬렉션이니까 복수형으로)
• 스토어(store)
클라이언트가 관리하는 자원 저장소
클라이언트가 리소스 URI 결정
PUT 기반 등록
예) /files (스토어니까 복수형으로)
• 컨트롤러(controller), 컨트롤 URI
문서, 컬렉션, 스토어만으로 해결하기 어려운 추가 프로세스 실행
동사(행위)를 URI에 직접 사용
예) /members/{id}/delete
참고 자료 & 이미지 출처
모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 님)
컴퓨터 네트워킹 : 하향식 접근 7판 (JAMES F.KUROSE)
'Web > HTTP' 카테고리의 다른 글
| HTTP Header - 일반 헤더 (0) | 2021.05.31 |
|---|---|
| HTTP 상태 코드 (0) | 2021.05.28 |
| HTTP 메서드 (0) | 2021.05.24 |
| HTTP 기본 (0) | 2021.05.17 |
| URI와 웹 브라우저 요청 흐름 (0) | 2021.05.17 |