이전 시간 학습 내용
라우터 분리하기에서 저는 회원에대한 routes(라우트)와 handler(핸들러)를 구현했고, 실제 DB와 연동하진 않았지만 엔드포인트에 따른 Call이 진행이 되도록 임시로 구현했습니다.
Goal
이제 실제로 구현하기에 앞서서 회원 정보 관리 요구사항을 정의해 보겠습니다.
회원 정보 관리 기능 정의(Requirements)
- 회원은 서비스에 계정을 생성 할 수 있어야 한다.
- 기존의 회원은 정보를 수정할 수 있어야 한다.
- 회원은 계정을 삭제할 수 있어야 한다.
- 한명에 회원에 정보를 조회할 수 있어야 한다.
- 회원 목록 정보를 조회 할 수 있어야 한다.
⛔️ 잘못된 API URI 디자인 설계
- 회원 등록 /create-user
- 회원 수정 /update-user
- 회원 삭제 /delete-user
- 회원 조회 /read-user-id
- 회원 목록 조회 /read-user-list
API URI을 어떻게 설계해야할까?
회원을 등록한다.
회원을 수정한다.
위 처럼 리소스+행위가 리소스가 아니다.
오로지 회원으로만 리소스를 식별하면 된다.
✅ 올바른 API URI 디자인 설계
위에 잘못된 API URI 디자인 설계에서 create-user에 뜻을 해석하면, 생성한다-회원이라는 뜻이다.
생성한다라는 행위와 회원이라는 자원이 합쳐져있다.
리소스와 자원을 분리해야한다.
users라는 리소스를 식별하여,URI계층에 구조를 활용하였다.
- 회원 등록 /uesrs/{id}
- 회원 수정 /users/{id}
- 회원 삭제 /users/{id}
- 회원 조회 /users{id}
- 회원 목록 조회 /users
REST API 디자인 가이드
첫 번째, URI는 정보의 자원을 표현해야한다.
⛔️ REST를 적용하지 못한 잘못된 URI
POST /users/insert/1URI는 자원을 표현하는데 중점을 두어야한다.
두 번째, 자원에 행위는 HTTP Method(GET, POST,PUT, DELETE)로 표현된다.
위에 REST를 적용하지 못한 잘못된 URI를 다음과 같이 변경이 가능하다.
POST /users/1
HTTP METHOD의 알맞은 역할
| METHOD | 역할 |
| POST | POST를 통해 해당 URI를 요청하면 리소스를 생성합니다. |
| GET | GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다. |
| PUT | PUT를 통해 해당 리소스를 수정합니다. |
| DELETE | DELETE를 통해 리소스를 삭제합니다. |
URI 설계 시 주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
- 경로가 긴 경우에는 하이픈(-)으로 URI 가독성을 높이는데 사용한다.
- 언더스코어(_) 는 URI에 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함시키지 않는다.