요구사항 | API URI 설계 |
• 회원 목록 조회 • 회원 조회 • 회원 등록 • 회원 수정 • 회원 삭제 |
• 회원 목록 조회 /read-member-list • 회원 조회 /read-member-by-id • 회원 등록 /create-member • 회원 수정 /update-member • 회원 삭제 /delete-member |
단적으로 위의 설계는 틀린 방식이다.
가장 중요한 것은 리소스 식별
API URI 고민
URI(Uniform Resource Identier)
• 리소스의 의미는 뭘까?
- 회원을 등록하고 수정하고 조회하는게 리소스가 아니다!
- 예) 미네랄을 캐라 -> 미네랄이 리소스
- 회원이라는 개념 자체가 바로 리소스다.
• 리소스를 어떻게 식별하는게 좋을까?
- 회원을 등록하고 수정하고 조회하는 것을 모두 배제
- 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
요구사항 | API URI 설계 |
• 회원 목록 조회 • 회원 조회 • 회원 등록 • 회원 수정 • 회원 삭제 |
• 회원 목록 조회 /members • 회원 조회 /members/{id} • 회원 등록 /members/{id} • 회원 수정 /members/{id} • 회원 삭제 /members/{id} |
참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)
리소스와 행위 분리
가장 중요한 것은 리소스를 식별하는 것
• URI는 리소스만 식별!
• 리소스와 해당 리소스를 대상으로 하는 행위을 분리
- 리소스: 회원
- 행위: 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사 (미네랄을 캐라)
• 행위(메서드)는 어떻게 구분?
'CS ( Computer Science ) > 네트워크 (Networking)' 카테고리의 다른 글
[Net] Cookie (1) | 2024.12.28 |
---|---|
[Net] MVC 패턴 (0) | 2024.12.13 |
[Net] Cookie / Session / Token / JWT / Filter (0) | 2024.12.12 |
[Net] 네트워크 기본 요약 (1) | 2024.12.06 |
[Net] Rendering (1) | 2024.12.05 |