한 화면에서 여러 속성을 수정할 수 있는 UI 가 있을 때,
API 구조를 어떻게 짜야할 지 고민이었다.
이른바 partial update 가 가능한 화면
GitHub 의 이슈 등록 화면이 내가 고민했던 UI 구조와 비슷해서 가져와봤다.
이슈 화면에는 제목, 내용, Assignees, Labels 등 수정 가능한 속성들이 참 많다.
Partial Update 에 대한 API 설계 방식.. 크게 2가지 중 고민이 되었다.
1. 하나의 API 로 퉁치기
- PATCH /issues/{id}
하나의 API 로 제목도 수정할 수 있고 Assignees 도 수정할 수 있는 구조다.
그렇게 하려면 서버에서는 api input 필드를 전부 옵셔널로 설정하고
클라이언트는 수정된 속성만 서버로 전송해야 할 것이다.
2. 수정이 일어날 수 있는 항목 별로 API 따로 제공
예를 들어..
- PATCH /issues/{id} -> 제목 및 내용만 수정하는 API
- PATCH /issues/{id}/assignees -> Assignees 만 수정하는 API
이럴 땐 역시 잘 개발되어 있는 타 사이트의 네트워크 탭을 확인하면 API 설계하는데 도움이 된다.
GitHub 과 Trello 를 참고해보니 2번 방식을 사용하고 있었다.
단, 죄다 API 분리하는건 아니고 하나의 API 로 묶을 수 있는 속성들은 묶어서 처리하고 있다.
그래서 내가 내린 결론은 "상황에 따라 설계가 달라질 수 있다" 이다.
2번 방식을 다시 보면 제목 혹은 내용을 수정하는 경우 하나의 API 로 묶여있다.
추측해보자면..
제목 혹은 내용을 수정하는 경우 테이블 1개(ex. ISSUE)의 특정 row 만 UPDATE 하겠지??
그러니까 굳이 "제목 수정 API" 와 "내용 수정 API" 로 분리할 필요가 없는 것이다.
하지만 Assignees 에 대한 수정이 일어나는 경우
USER 테이블과 ISSUE 테이블을 잇는 many-to-many 테이블에 수정이 일어나야 할 것이다.
그니까 Assignees 를 수정할 때는 "제목 수정 API" 와 묶여질 수 없을 것이다.
내부 로직이 달라지기 때문에 API 분리하는게 더 낫기 때문이다.