REST 서비스 프로젝트를 해보면, 여전히 많은 시행 착오를 겪는 거 같습니다.

왜 이렇게 해야 하고, 이러한 구조를 가져야 하는지... URI에 쿼리 파라미터로 데이터를 전송해야할 지 메세지 바디에 데이터를 전송해야할 지 등등

그래서 이번 페이지는 URI의 좋은 설계와 HTTP API 의 좋은 설계에 대해서 이야기를 이끌어가볼까 합니다.

어떤 설계가 좋은 URI 설계일까요?

정답부터 말하자면, 바로 리소스를 어떻게 식별했는지가 바로 좋은 설계를 나누는 기준이 됩니다.

그렇다면 리소스란 무엇일까요?

• 예를 들어 강아지가 움직인다 에서 리소스는 동사인 움직인다가 아닌 강아지가 된다.
• 즉 만약 회원을 등록하고 수정하는 URI가 있다면 여기서 리소스는 회원이 되는 것이다.

URI 설계 예시

• 학생 전체 조회 ⇒ /students
• 학생 조회 ⇒ /students/{std_id}
• 학생 등록 ⇒ /students/{std_id}
• 학생 삭제 ⇒ /students/{std_id}

<aside> 💡 이때, student가 아닌 students로 설계한 이유는 복수적인 계층구조를 표현하기 위해서 사용했다.

</aside>

다 같은 URI 계층이면 어떻게 구분할 것인가?

• 바로 HTTP 메서드를 통해서 행위를 구분할 것이다.

예를 들어, 학생 조회랑 학생 등록을 구분하는 좋은 설계는 바로

조회 : /students/{std_id} → GET 사용 / 등록 : /students/{std_id} ⇒ POST 사용 으로 설계한다.