API 설계 고민: 추가, 수정, 삭제가 한 번에 일어나는 구조

 
오늘은 내가 했던 API 설계 고민을 공유해볼것임

 
 
 
어느 날 회사에서 아래와 같은 시안을 건네 받았음
(회사꺼는 공개할 수 없기에 Tistory 관리자 페이지에서 최대한 비슷한 구조의 UI 를 가져왔슴다)

 
이 시안이 뭣이냐하면.. 
우측 하단에 [변경사항 저장] 버튼을 누르면 CRUD 가 한 번에 일어나는 구조의 페이지임
 
 
삭제 혹은 수정만 하는 API 는 설계하기 쉬운데 CRUD 가 한 번에 일어나야한다고 생각하니 갑자기 머리가 지끈해짐
[저장] 버튼 누를 때 변경사항 있는 row 들은 API payload 로 전부 전달을 해야할 터인데...
API 서버 입장에서 각 row 들이 수정/삭제/추가 중에 무엇인지는 어떻게 구분하지????

 
 
 
아!!! row 에 id 값이 있으면 수정 혹은 삭제,  id 값이 없으면 추가로 구분해야겠구나? 난 혹시 천재?????

 
 
 
이러고 뚝딱뚝딱 만들었음... 근데.. 정상 작동은 하는데.. 코드가 너무 복잡쓰.. 
5일 뒤에 해당 API 코드를 다시 보니 1도 안 읽히고 뭔 생각으로 이렇게 짰는지 잘 기억이 안 났음
사태의 심각성을 인지....

 
(그런데 변명하자면... 회사 내 일부 직원분들만 쓸 페이지라서 설계 고민 크게 안 하고 뚝딱 만든 것도 있음.. 그냥.. 그렇다구요..하하)
 
 
그래서 급 코드를 수습하기 시작했는데..
operationType 이라는 필드를 둬서 해당 row 가 CREATE, UPDATE, DELETE 중 어떤 값인지 구분하도록 수정함
아래와 같은 구조임

{
  "products": [
    {
      "operationType": "CREATE",
      "title": "맛있는 사과"
    },
    {
      "id": 23,
      "operationType": "UPDATE",
      "title": "달콤한 오렌지"
    },
    {
      "id": 28,
      "operationType": "DELETE",
      "title": "시원한 수박"
    }
  ]
}

 
그래서 서버에서는 배열을 loop 돌며 if 문으로 분기 처리해서 DB에 어떤 작업을 수행할 지 결정했음
이 row 의 operationType 이 CREATE면, ~~
UPDATE면, ~~
DELETE면, ~~~~
..
 
이러니까 훨씬 코드 보기에 편안해졌음

 
 
 
그런데 문득 지금 이 글을 쓰면서 생각이 든 건..
아래와 같이 CREATE/UPDATE/DELETE 를 key 값으로 하는 배열로 받아도 좋았을 것 같다.
그러면 loop 돌면서 if 분기 처리 안 해도 되니까!!!

{
  "DELETE": [
    {
      "id": 23
    }
  ],
  "CREATE": [
    {
      "title": "달콤한 오렌지"
    }
  ],
  "UPDATE": [
    {
      "id": 9,
      "title": "새콤한 딸기"
    },
    {
      "id": 13,
      "title": "아삭한 사과"
    }
  ]
}

 
 
 
 
음.. 이건 갑자기 생각난거니까.. 언젠가 기회가 된다면 리팩토링 할거임.. 지금 할 일이 많아서..
(이러고 평생 안 고쳐졌다고 한다)
그럼 이만..