첫번째 프로젝트 URL 설계도

위의 그림이 프로젝트에 등록된 URL의 거의 전부이다. AuthController도 있지만 이 Controller는 페이지를 출력해주는 역할이기 때문에 포함시키지 않았다.

REST API 설계 가이드를 살펴보자

조대협님의 블로그 포스팅된 설계 가이드를 참고해서 프로젝트에서 안티 패턴을 찾아내고 리팩토링해보자

1. REST URI를 심플하고 직관적으로 만들자

• URL은 최대 2 depth정도로 간결하게 만들자
• URI에 자원의 이름은 명사를 사용하자 (가급적이면 복수형 명사를 사용하자)

2. 권장하는 리소스간의 관계 표현법

• 서브 자원으로 표현하는 방법
  ex) 사용자가 가지고 있는 스터디 목록을 표현한다고 할 때 GET /members/{memberIdx}/studies
• 서브 자원에 관계를 명시하는 법
  ex) 사용자가 등록한 스터디 목록을 표현한다고 할 때 GET /members/{memberIdx}/register/studies

3. 에러처리

• HTTP Response Code를 사용한 후 Response body에 error detail을 서술하는 것이 좋다.

그 외 페이징, API 버전 관리, Partial Resonse 처리, 검색, 링크처리 등에 대한 가이드를 제공하고 있지만 이번 프로젝트에서는 필요한 가이드가 아니기 때문에 생략하기로 하겠다.

내 프로젝트 리팩토링

• GET을 이용한 터널링 사례 리팩토링

  GET을 이용한 터널링은 실제로는 자원을 수정(PUT)하는 요청이지만 GET을 이용하여 요청을 처리하는 경우를 말한다. 나의 프로젝트에서 다수 찾을 수 있었다. 따라서 다음과 같이 수정했다.

  • STUDY 관련 수정 내용
    POST /create-study/save -> POST /api/v1/studies
GET /study/delete/{idx} -> DELETE /api/v1/studies/{idx}
GET /admin/study/fire/{idx} -> DELETE /admin/api/v1/studies/{idx}
GET /admin/change-status-incruit/{idx} -> PUT /admin/api/v1/studies/{idx}/status
GET /admin/change-status-open/{idx} -> PUT /admin/api/v1/studies/{idx}/status
GET /admin/change-status-close/{idx} -> PUT /admin/api/v1/studies/{idx}/status
POST /update-study/{idx} -> PUT /api/v1/studies/{idx}

  • MEMBER 관련 수정 내용
    GET /study/unregister/{idx} -> PUT /api/v1/members/
GET /admin/member/change-role-student/{idx} -> PUT /admin/api/v1/members/{idx}/role
GET /admin/member/change-role-leader/{idx} -> PUT /admin/api/v1/members/{idx}/role
GET /admin/member/change-role-admin/{idx} -> PUT /admin/api/v1/members/{idx}/role
GET /study/unregister/{idx} -> PUT /api/v1/members/unregister/studies/{idx}
GET /study/register/{idx} -> PUT /api/v1/members/register/studies/{idx}
POST /signup/request -> POST /api/v1/members
POST /change-password/request -> PUT /api/v1/members/{email}/password
GET /admin/member/fire/{idx} -> DELETE /api/v1/members/{idx}

• REST API 설계 가이드 따르지 않은 사례 리팩토링
  GET /study -> GET /studies
GET /study/detail/{idx} -> GET /studies/{idx}
GET /create-study -> GET /studies/save
POST /signin/request -> POST /signin
GET /forgot-id -> GET /findid
GET /forgot-password -> GET /findpassword
GET /change-password/{email} -> GET /changepassword/{email}
GET /forgot-id/{studentNumber} -> GET /api/v1/members/{studentNumber}/email
GET /forgot-password/{email} -> GET /api/v1/members/{email}

리팩토링 근거

1. API URL과 단순 화면 렌더링 URL을 분리

   jojoldu님의 책 "스프링 부트와 AWS로 혼자 구현하는 웹 서비스"에서는 API의 URL과 단순 화면을 렌더링하는 URL을 분리했다. 이를 참고하여 필자의 프로젝트에도 api와 분리를하여 관리하도록 리팩토링했다.

2. 단수형으로 표현한 자원의 이름을 복수형으로 표현

3. 자원간의 관계를 표현하도록 depth를 설계

   ex) GET /api/v1/members/{studentNumber}/email
   (studentNumber가 {studentNumber}인 member의 email을 요청)

4. 직관적이지 않은 URL을 직관적으로 표현 & 쓸모없는 특수문자 제거
   ex) /forgot-id -> /findid

리팩토링 결과

• URL의 변화변화
  
  URL이 훨씬 더 REST하게 바꼈다. REST를 아는 사람과 협업을 한다면 더욱 의사소통이 원활하게 협업할 수 있을 것 같다.

• 코드 다이어트
  리팩토링을 하다가 코드의 반복을 발견해서 반복을 제거하며 코드의 양이 줄었다. 이는 후에 유지보수하기 더욱 용이할 것이다.

남은 숙제

• AJAX 코드 리팩토링
• HTTP CODE로 RESPONSE하기
• HTML CSS로 레이아웃 직접 짜보기

공부해야 할 것들이 너무 많다. 공부에 쫓기지말고 즐기면서 천천히 앞으로 나아가기를 원한다. 첫번째 프로젝트를 붙잡은지 4달이 지났다. 느리지만 거의 다 왔다. HTTP CODE로 RESPONSE하는 것을 마지막으로 첫번째 프로젝트를 분석하고 리팩토링하는 작업은 끝내고자 한다. 그리고 두번째 프로젝트를 통해 성장할 것이다. 화이팅