목차
1. HTTP API
위와 같은 요구 조건의 HTTP API 설계 시 URL을 어떻게 해야하는지에 대해 고민해보겠습니다.
1) 잘못된 HTTP API 설계
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member
"회원을 읽는 것" 은 리소스가 아닙니다. "회원" 자체만 리소스입니다. 따라서 API 는 아래와 같은 방식으로 작성하는 것이 좋습니다.
2) 옳은 HTTP API 설계
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
그러나 이러한 API 설계는 조회,등록,수정,삭제 라는 행위를 구분하지 못하는 문제가 발생합니다. 이를 해결하기 위해 HTTP 메서드가 필요합니다.
2. HTTP 메서드
1) GET방식
특징
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달
- 메시지 바디를 사용해 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장 X
통신 과정
1) 메시지 전달
members/100을 url에 넣고 get방식으로 서버에 request하면
서버는 /member/100에 해당하는 데이터를 찾습니다.
2) 메시지 응답
이후 클라이언트에게 값이 전달됩니다.
2) POST방식
특징
- 요청 데이터 처리
- 메시지 바디를 통해 서버로 요청 데이터를 전달
- 서버는 요청 데이터를 처리
- 주로 전달된 데이터로 신규 리소스를 등록하거나 프로세스를 처리하는데에 사용됨
통신과정
1) 메시지 전달
2) 신규 리소스 생성
3) 메시지 응답
POST 정리
1. 새 리소스를 생성하는데에 사용합니다.
2. 요청 데이터를 처리하는데에 사용합니다.
-> 배달 시작 -> 배달 완료처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우 등이 있습니다.
3. 다른 메서드로 처리하기 어려운 경우 사용합니다.
-> 예를 들어 GET 방식으로 조회하고 싶은데, 데이터를 JSON으로 url에 넘길 수 없는 경우가 있습니다. 이런 경우 POST로 바디에 JSON 리소스를 담아 전달하고 서버에서 JSON 리소스를 조회합니다.
3) PUT방식
특징
- 리소스를 통째로 대체, 리소스가 없으면 생성 (덮어쓰기)
- 클라이언트가 리소스의 전체 경로를 알고 있습니다.
아래 그림을 보면 클라이언트가 members/100 처럼 전체 경로를 알고 있습니다.
4) PATCH방식
특징
- 리소스를 부분 변경
3. HTTP 메서드 속성
1) 안전
- 호출해도 리소스를 변경하지 않는다.
2) 멱등
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같습니다.
- 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거로 작용합니다.
- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않습니다.
GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회됩니다.
PUT: 같은 요청을 여ㄹ번 해도 최종 결과는 같습니다.
DELETE: 같은 요청으로 같은 삭제를 하므로 결과는 같습니다.
POST: 멱등이 아닙니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있습니다.
3) 캐시가능
- GET, HEAD 정도만 캐시로 사용하고, POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않아 잘 쓰지 않습니다.
4. HTTP 메서드 활용
1) 데이터 전달 방식
쿼리 파라미터를 통한 데이터 전송
- GET
- 주로 정렬 필터(검색어)
메시지 바디를 통한 데이터 전송
- POST, PUT, PATCH
- 회원 가입, 상품 주문, 리소스 등록, 리소스 변경
2) 데이터 전송 4가지 상황
1. 정적 데이터 조회 - 쿼리 파라미터 미사용
- 이미지, 정적 텍스트 문서
- 조회는 GET 사용
- 정적 데이터는 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능
2. 동적 데이터 조회 - 쿼리 파라미터 사용
- 주로 검색, 게시판 목록에서 정렬 필터
- 조회 조건을 줄여주는 필터, 결과를 정렬하는 정렬 조건에 사용
- 조회는 GET 사용
3. HTML Form 데이터 전송
1) POST 전송 - 저장
2) GET 전송 - 저장
단, GET은 조회에서만 사용해야하고, 리소스 변경이 발생하는 곳에서 사용하면 안됩니다.
3) GET 전송 - 조회
4. HTML API를 통한 데이터 전송
- 서버끼리 통신
- POST, PUT, PATCH로 메시지 바디를 통해 데이터 전송
- GET 조회로 쿼리 파라미터 데이터 전달
5. HTTP API 설계 예시
1) 회원 관리 시스템 API 설계 - POST 기반 등록
- 회원 목록 /members -> GET
- 회원 등록 /members -> POST
- 회원 조회 /members/{id} -> GET
- 회원 수정 /members/{id} -> PATCH, PUT, POST
- 회원 삭제 /members/{id} -> DELETE
회원 관리 시스템 POST - 신규 자원 등록 특징
- 클라이언트는 등록될 리소스 URI를 모른다.
- 서버가 새로 등록된 리소스 URI를 생성한다.
- 컬렉션 = 서버가 관리하는 리소스 디렉토리
2) 파일 관리 시스템 API 설계 - PUT 기반 등록
- 파일 목록 /files -> GET
- 파일 조회 /files/{filename} -> GET
- 파일 등록 /files/{filename} -> PUT
- 파일 삭제 /files/{filename} -> DELETE
- 파일 대량 등록 /files -> POST
파일 관리 시스템 PUT - 신규 자원 등록 특징
- 클라이언트가 리소스 URI를 알고 있어야 한다.
- 클라이언트가 직접 리소스 URI를 지정한다.
- 스토어 = 클라이언트가 관리하는리소스 저장소 ex) /files/star.jpg
3) HTML FORM 사용
- 회원 목록 /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
특징
- HTML FROM은 GET, POST 방식만 지원
- GET, POST 만으로는 제약이 있으므로 동사로 된 리소스 경로를 최소한으로 사용한다. ex) /new, /edit, /delete
김영한님 인프런 강의를 듣고 복습용으로 기록
'IT > HTTP' 카테고리의 다른 글
| [HTTP] HTTP 헤더 (0) | 2022.06.05 |
|---|---|
| [HTTP] HTTP 상태코드 (0) | 2022.06.04 |
| [HTTP] HTTP 기본 (0) | 2022.06.03 |
| [HTTP] 인터넷 네트워크 (0) | 2022.06.01 |