개요
- 리소스 : 명사
- HTTP 메서드 : 동사(행위)
- 즉 개발자는 리소스만 식별해주면 나머지 동적인 부분은 HTTP 메서드(GET , POST , PUT , PATCH , DELETE)가 해줌
1. HTTP API 방식(Content-Type: application/json) URI 설계
개요
-
REST API 방식은 POST 기반 등록과 PUT 기반 등록이 존재
-
등록(Create) 시 POST로 등록할 때와 PUT으로 등록할 때의 차이가 있음 한번 살펴볼 것임
① 회원 관리 시스템 : POST 기반 등록
설계 예시
- 회원 목록 : /members GET
- 회원 등록 : /members POST
- 회원 조회 : /members/{id} GET
- 회원 수정 : /members/{id} POST , PUT , PATCH
- 회원 삭제 : /members/{id} DELETE
수정 시 PUT VS PATCH
-
PUT : 전체 수정
-
PATCH : 부분 수정
-
PUT보단 PATCH 주로 씀 , 클라이언트가 수정할 내용만 Body에 JSON 형태로 적어서 전송하면 해당 부분만 수정되므로 , PUT은 내용 하나라도 빠지면 빠진 데이터 전부 사라지니
-
PUT은 게시글 수정 시에 주로 쓰임 , 게시판 글 수정버튼 누르면 전체 글이 수정되어야 하므로
POST 기반 등록 과정
-
클라이언트가 /members POST로 등록 요청 => 서버는 회원 등록 후 신규 등록된 리소스를 식별할 수 있는 최종 URI를 만듬(/members/{id}) => 서버는 클라이언트에게 /members/{id} 응답
-
즉 클라이언트 입장에서 정확한 리소스는 서버에 저장된 후에 알 수 있음
컬렉션(Collection)
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URI를 생성하고 관리
- 여기서 컬렉션은 /members가 됨
- 클라이언트가 아닌 서버가 새로 등록될 URI를 생성하고 관리할 경우 그를 컬렉션이라고 함
➤ 등록 시점에 클라이언트는 새로 할당될 리소스를 식별할 수 없고 오직 서버만이 결정함
POST 기반 등록 특징
-
컬렉션에서 리소스 관리
-
즉 서버에서 리소스를 생성하고 관리하므로 등록 시점(/members POST 요청)에 클라이언트는 리소스를 식별할 수 없음
-
따라서 클라이언트는 서버에 등록된 후에 조회 , 수정 , 삭제와 같은 작업 가능
② 파일 관리 시스템 : PUT 기반 등록
설계 예시
- 파일 목록 : /files GET
- 파일 대량 등록 : /files POST
- 파일 한 개 등록 : /files/{filename} PUT
- 파일 조회 : /files/{filename} GET
- 파일 삭제 : /files/{filename} DELETE
특징
- 해당 방식은 등록이지만 POST가 아닌 PUT
➤ 파일은 등록 시 해당 리소스 경로에 파일이 존재하면 대체해서 등록하므로 PU - 등록 시 클라이언트가 리소스의 URI를 알고 있음
➤ 파일 저장 시 자기 자신이 파일 경로 및 파일 이름을 지정하여 저장하므로 - PUT 기반 수정 개념이 없음 , 오직 대체 or 신규 등록
스토어(Store)
- 클라이언트가 리소스를 만들고 관리하는 것을 스토어라고 함
- 즉 예시에서 스토어는 /files
정리
-
POST 기반 등록 : 서버가 리소스를 식별하므로 서버 리소스 관리 저장소인 컬렉션에서 리소스를 관리
-
PUT 기반 등록 : 클라이언트가 리소스를 식별하므로 클라이언트 리소스 관리 저장소인 스토어에서 관리
2. HTML Form(Content-Type: application/x-www-form-urlencoded) 방식
설계 예시
회원 목록 : /members GET
회원 등록 폼 조회 : /members/new GET
회원 등록 : /members/new POST
회원 조회 : /members/{id} GET
회원 수정 폼 조회 : /members/{id}/edit GET
회원 수정 : /members/{id}/edit POST
회원 삭제 : /members/{id} POST
특징
-
HTML Form 방식은 GET , POST 만 지원하므로 컨트롤 URI 를 써야함
-
컨트롤 URI는 동사로 된 리소스로 HTTP 메서드로 해결하기 어려우면 씀
-
최대한 리소스 개념으로 설계하고 정 안 되면 컨트롤 URI 쓰자
-
HTTP API 방식에서도 가능 , PUT DELETE PATCH 써도 리소스 명명하기 어려울 수 있으므로
추가적인 URI 설계 개념
1. 문서(document)
- /members/{id} 리소스에서 {id}와 같이 단일 값의 리소스
2. 컬렉션(collection)
- 서버가 관리하는 리소스 저장소
- HTTP API 방식에서 POST 기반 등록 시에 해당
- 즉 클라이언트는 서버에 등록 후에 리소스를 알 수 있으니 등록 후 수정 , 삭제 , 조회 작업이 가능
3. 스토어(store)
- 클라이언트가 관리하는 리소스 저장소
- HTTP API 방식에서 PUT 기반 등록 시에 해당
- 클라이언트가 등록 시에 리소스를 식별하고 등록
4. 컨트롤러(controller) , 컨트롤 URI
- 일반적인 명사 리소스만으로 리소스를 식별하기 어려울 때 컨트롤 URI를 통해 리솟에다가 추가적으로 컨트롤 URI를 적어줘서 URI를 매핑 가능
