한 달간의 프로젝트를 마치고, 멘토들에게 피드백을 받았다.
그 중 하나가 URI 설계에 대한 이야기였는데, 올바른 설계를 했는지 생각해보기로 했다.
1. URI 의미 🤔
- URI의 풀네임
Uniform Resource Identifier - 리소스 식별이 목적
:행동이 아닌행위 주체만을 주목해야 한다.
행동은 HTTP 메서드가 나타내주기 때문이다.
2. RESTful
REST는 Representational State Transfer의 약자이다. 자원을 URI로 표시하고 해당 자원의 상태를 주고 받는 것을 의미한다.
REST의 구성요소
-
자원(Resource): URI
-
행위(Verb): HTTP METHOD
-
표현(Representations)
따라서, REST는 URI를 통해 자원을 표시하고 HTTP METHOD를 이용하여 해당 자원의 행위를 정해주며 그 결과를 받는 것을 말한다.
출처 : https://ukcasso.tistory.com/63
3. URI 규칙
- 동사형이 아닌 명사형 (리소스 식별)
- 복수단어 사용 권장
- URI에 자원과 id 정보만 들어가야 한다.
- URI 경로를 통해 리소스의 계층 관계를 표현한다.
/리소스(Collection)
/리소스(Collection)/고유ID(Document)
/리소스(Collection)/고유ID(Document) /하위리소스(Collection)
/리소스(Collection)/고유ID(Document) /하위리소스(Collection)/하위리소스고유ID(Document)
출처: https://eblo.tistory.com/444. 리팩토링
발견한 문제점들
- URI에 동사형 단어가 포함되어 있다.
- 자원 정보 말고도 쓸데 없는 단어가 포함되어 있다.
수정 과정
- 개인 엑셀 정리
자원을 분류하고, 메서드별로 정리해서 URI를 정리했다. 이 과정에서 URI 네이밍 규칙이나 설계를 고려해 보려고 노력했다.
또한 리소스의 계층 관계를 URI에 표현하는 것이 좋다고 하여 원래는 기능별로 묶어 둔 URI를 자원의 계층구조를 중점으로 생각해서 다시 짜보았다.
- 팀원들과 함께 회의를 통해 결과물 도출
수정 후
- BucketList 프로젝트 스웨거 주소 :
https://www.ourbucketlist.link/swagger-ui/index.html
5. 소감
내용을 정리하고 생각해보니, front를 만들어 웹 서비스를 런칭하려는 것에만 급급 하다보니 REST API란 무엇인지, URI의 설계 및 규칙에는 무엇이 있는지 신경쓰지 못했다.
REST API에 대해 더 알아볼 수 있는 시간이었고, 백엔드 개발자 희망자로써 가져야 하는 자세에 대해 책을 보며 더 알아가 볼 예정이다.
