RESTful API ! 구현해봅시다

REST vs 개발 상황, 어떡하지?

완벽? 개발 상황을 고려하자

RESTful API ! 구현해봅시다

RESTful API를 설계하고 구현하기 위해 고민했습니다. 특히 한 눈에 알아보기 쉬운 API를 만드는 것에 초점을 맞췄습니다. HTTP Method를 통해 API의 기능을 나타내고 URI를 통해 자원을 명시하는 REST의 기본에 충실하려 노력했습니다.

REST vs 개발 상황, 어떡하지?

하지만 구현 중 제한적인 HTTP Method로 인해 개발 상황과 REST의 개념이 충돌하는 상황이 발생했습니다. 개발 상황은 아래와 같습니다.

1. task 생성 시 필수 요소가 아닌 값은 입력하지 않고 이 값들은 null 로 저장
2. task 를 수정할 수 있는 상황은 2가지
   1. 수정 모달 : 전체 값 중 원하는 값을 수정
   2. 메인 화면 : 드래그 앤 드랍으로 태그를 수정, 완료 체크박스를 통해 완료 상태 수정
3. 위의 각 상황은 별개의 상황으로 취급되어 task 수정 API 역시 2가지
4. 각 상황의 API HTTP Method
   1. 수정 모달 → task 생성 시와 마찬가지로 필수 요소가 아닌 값은 원하는 요소만 입력 → 부분 수정 → PATCH
   2. 메인 화면 → 태그 및 완료 상태만 수정 → 부분 수정 → PATCH

task 와 관련된 PATCH API 두 개가 필요한 위 상황에서 각 API에 REST의 조건을 만족하는 URI를 어떻게 설정해야 할지 많은 고민을 했습니다. 결국 HTTP Method를 PATCH 로 하고 URI를 /task/:task_idx 로 하는 두 개의 API가 필요하기 때문에 많은 고민이 되었습니다. 생각한 방법은 아래의 두 가지입니다.

1. 한 API의 HTTP Method를 PUT 으로 수정
   1. 수정 모달 : PUT /task/:task_idx
   2. 메인 화면 : PATCH /task/:task_idx
2. API의 URI를 수정
   1. 수정 모달 : PATCH /task/status/:task_idx → 태스크의 상태(태그 및 완료 상태)만 수정
   2. 메인 화면 : PATCH /task/update/:task_idx → 태스크의 모든 정보를 (일부) 수정 가능, 위의 URI 수정 시 /task/:task_idx 로 유지할 수 있으나 혼란 방지

위 두 가지 방법 중 고민 끝에 두 번째 방법을 선택하게 되었습니다. 첫 번째 방법은 일부만 수정하는 API의 HTTP Method를 PATCH가 아닌 PUT으로 지정한다는 점에서 적절하지 않은 HTTP Method를 선택하는 것이 REST에 위반되고 두 번째 방법은 URI에 행위에 대한 정보를 포함한다는 점에서 REST에 위반된다는 생각이었습니다. 결국 두 방법 모두 REST에 위반되는 것은 마찬가지이고 복잡한 개발 상황에서는 완전한 RESTful API를 구현하지 못할 수 있다는 것을 깨달았습니다. 따라서 기능의 정보를 포함하는 HTTP Method를 위반하는 것보다는 URI 규칙을 위반하는 것이 정보의 왜곡을 줄일 수 있다는 생각에 두 번째 방법을 선택하였습니다.

완벽? 개발 상황을 고려하자

REST는 제한적인 HTTP Method를 제공하기 때문에 이런 일이 발생하였고 이는 REST의 단점이자 한계점이라는 생각을 했습니다. 복잡한 개발 상황에서는 완벽한 RESTful API의 구현이 힘들 수 있고 완벽한 RESTful API를 좇기보다는 개발 상황에 적합한 선택을 하기 위해 노력하는 것이 최선이라는 생각이 들었습니다.