1. 클라이언트에서 서버로 데이터 전송
데이터를 전달하는 방식은 크게 2가지가 있습니다.
1. 쿼리 파라미터를 통한 데이터 전송
GET 메서드를 주로 사용합니다. 주로 정렬 필터를 쓸 때 많이 사용합니다. (검색어, 정렬 조건 등)
2. 메시지 바디를 통한 데이터 전송
POST, PUT, PATCH 메서드를 사용합니다. 회원 가입이나 상품 주문, 리소스 등록, 변경 시 주로 사용합니다.
그리고 클라이언트에서 서버로 데이터를 전송하는 상황을 아래의 4가지로 나누어 볼 수 있습니다.
1. 정적 데이터 조회
이미지, 정적 테스트 문서
2. 동적 데이터 조회
주로 검색, 게시판 목록에서 정렬 필터(검색어)
3. HTML Form을 통한 데이터 전송
회원 가입, 상품 주문, 데이터 변경
4. HTTP API를 통한 데이터 전송
회원 가입, 상품 주문, 데이터 변경 • 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)
위 4가지 상황에 대해 살펴보겠습니다.
(1) 정적 데이터 조회
이미지나 정적 텍스트 문서를 조회하는 것입니다. 주로 GET 메서드를 사용합니다.
정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회할 수 있습니다.
(2) 동적 데이터 조회
조회 시에 데이터를 전달해주어야 하는 경우도 있습니다. 예를 들어 구글에서 검색을 한다고 했을 때 검색어를 쿼리파라미터에 넣어서 요청하게 됩니다. 이처럼 주로 검색이나 정렬 필터 등에 주로 사용됩니다.
조회는 GET을 사용하고, 쿼리 파라미터를 사용해 데이터를 전달합니다.
(3) HTML Form을 통한 데이터 전송
1. POST 전송 - 저장
메서드가 post면 메시지 바디에다가 데이터 값을 넣습니다. Content - Type에 urlencoded는 url을 인코딩 상태로 전달하는 것입니다.
2. GET 전송 - 조회
메서드가 GET이라면 쿼리 파라미터에 데이터 값이 들어갑니다.
주의해야할 것은 GET은 조회에만 사용하는 것이라, 리소스 변경이 발생하는 곳에는 사용해서는 안됩니다.
3. multipart/form-data
파일을 전송할 때 쓰입니다.
위 그림에서 user와 name 뿐 아니라 file도 함께 전송하는 것을 볼 수 있습니다. 이럴 때, multipart form data 라는 메시지 바디에 넣는 형식을 사용해야 합니다. 요청 HTTP 메시지의 Content-Type이 multipart/form-data로 들어가고 boundary라는 것을 통해 자릅니다.
그래서 username과 age, file 이 바운더리로 나뉘게 되고 file에는 content type과 바이너리 코드가 함께 들어갑니다.
(4) HTTP API를 통한 데이터 전송
서버 to 서버로 백엔드끼리 데이터를 전송할 때에 많이 쓰입니다. 이 외에도 백엔드 시스템 통신과, 앱 클라이언트, HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)됩니다(React, VueJs 같은 웹 클라이언트와 API 통신 ).
주로 Content-Type: application/json을 사용합니다. (사실상 표준)
POST, PUT, PATCH일 때는 메시지 바디를 통해 데이터를 전송하고 GET 을 사용할 때는 쿼리 파라미터로 데이터를 전송합니다.
2. HTTP API 설계 예시
(1) 회원 관리 시스템
만약 회원 관리 시스템을 설계한다고 가정해보겠습니다. 회원에 대한 기능은 아래와 같이 설계할 수 있습니다.
API 설계 - POST 기반 등록
- 회원 목록 : /members -> GET
- 회원 등록 : /members -> POST
- 회원 조회 : /members/{id} -> GET
- 회원 수정 : /members/{id} -> PATCH, PUT, POST
- 회원 삭제 : /members/{id} -> DELETE
POST 기반의 신규 자원 등록에서는 클라이언트는 등록될 리소스의 URI를 모르는 상황입니다,
• 회원 등록 /members -> POST
• POST /members
그래서 이처럼 서버가 새로 등록된 리소스 URI를 생성합니다.결과는 HTTP/1.1 201 Created Location: /members/100 등의 예시로 나오게 됩니다.
(2) 파일 관리 시스템
파일 관리 시스템의 예시에서는 아래와 같이 설계할 수 있습니다.
API 설계 - PUT 기반 등록
- 파일 목록 /files -> GET
- 파일 조회 /files/{filename} -> GET
- 파일 등록 /files/{filename} -> PUT
- 파일 삭제 /files/{filename} -> DELETE
- 파일 대량 등록 /files -> POST
파일 관리 시스템과 같은 PUT 기반 등록에서는 클라이언트가 리소스 URI를 알고 있어야 합니다.
• 파일 등록 /files/{filename} -> PUT
• PUT /files/star.jpg
이처럼 클라이언트가 직접 리소스의 URI를 지정합니다. 특히 파일 등록 시 PUT 메서드는 만약 이미 똑같은 경로에 파일이 존재한다면 덮어씌워야 하기 때문에 필요합니다.
PUT과 POST 중에 대부분은 POST 기반의 등록을 사용합니다.
(3) HTML FORM 사용
HTML FORM은 GET, POST만 지원합니다. AJAX 같은 기술을 사용해서 해결 가능하지만 여기서는 순수 HTML, HTML FORM 이라고 가정하겠습니다. GET, POST만 지원하므로 제약이 있습니다.
- 회원 목록 : /members -> GET
- 회원 등록 폼 : /members/new -> GET
- 회원 등록 : /members/new, /members -> POST
- 회원 조회 : /members/{id} -> GET
- 회원 수정 폼 : /members/{id}/edit -> GET
- 회원 수정 : /members/{id}/edit, /members/{id} -> POST
- 회원 삭제 : /members/{id}/delete -> POST
GET, POST만 지원하므로 제약이 있습니다 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용합니다. POST의 /new, /edit, /delete가 컨트롤 URI • HTTP 메서드로 해결하기 애매한 경우에 사용합니다(HTTP API 포함).
참고하면 좋은 URI 설계 개념
https://restfulapi.net/resource-naming/
- 문서(document)
• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• 예) /members/100, /files/star.jpg - 컬렉션(collection)
• 서버가 관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• 예) /members - 스토어(store)
• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• 예) /files - 컨트롤러(controller), 컨트롤 URI
• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예) /members/{id}/delete
참고자료
[인프런 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식]
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
'Backend > HTTP' 카테고리의 다른 글
[HTTP] HTTP 헤더 - 일반 헤더 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 7) (0) | 2023.04.25 |
---|---|
[HTTP] HTTP 상태코드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 6) (0) | 2023.04.25 |
[HTTP] HTTP 메서드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 4) (0) | 2023.04.21 |
[HTTP] HTTP 기본 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 3) (0) | 2023.04.20 |
[HTTP] URI와 웹 브라우저 요청 흐름 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 2) (0) | 2023.04.18 |