[API] 위젯 데이터 받아오기 방식의 변경(1)

Onit의 페이지 구조

• Onit의 회원은 개인 페이지를 가지게 되고 위젯을 배치해서 자유롭게 페이지를 꾸밀 수 있다.
  • 개인페이지를 normal페이지라고 부른다.
  • 개인페이지를 수정할 수 있는 페이지를 edit 페이지라고 부른다.
  • 접속 url은 ${domain}/${user_seq}/normal, ${domain}/${user_seq}/edit로 나누어져 있다.
  • 3번 유저는 3번 유저의 normal, edit 페이지에 모두 접근 가능하다.
  • 4번 유저는 3번 유저의 normal 페이지에는 접근이 가능하지만 edit 페이지에는 접근할 수 없다.
  • normal 페이지와 edit 페이지에서 쓰는 위젯의 정보는 동일하다.

📦 기존에 데이터를 받아온 방식

두 페이지에서 데이터를 요청하는 api가 따로 있었다.

• normal 페이지 접속 플로우

1. 4번 유저가 3번 유저의 normal 페이지에 접속
2. 클라이언트에서 3번 유저의 위젯 정보를 요청한다.
   • 요청 url:/user/:user_seq/widgets/normal
   • Header에 access token을 보낸다.
3. 서버에서 /user/:user_seq/widgets/normal로 요청이 오는 경우
   • access token은 넘어오지만 인증이 필요없는 페이지이므로 인증여부를 확인하지 않는다.
   • 위젯 데이터를 보낸다.
4. 클라이언트에서 받은 위젯 데이터를 화면에 뿌린다.

• edit 페이지 접속 플로우

1. 4번 유저가 3번 유저의 edit 페이지에 접속
2. 클라이언트에서 3번 유저의 위젯 정보를 요청한다.
   • 요청 url:/user/:user_seq/widgets/normal
   • Header에 access token을 보낸다.(현재 접속유저인 4번 유저의 access token이 전송됨)
3. 서버에서 /user/:user_seq/widgets/edit로 요청이 오는 경우
   • access token을 체크하여 토큰이 만료되었거나(419) 유효하지 않거나(401) 정보를 요청하는 유저와 정보를 owner가 다른 경우에(601) 각각 status를 설정하고 에러 상황으로 인지한다.
   • 에러 상황에는 위젯 데이터를 보내지 않는다.
4. 클라이언트에서는 status code를 확인하여 200인 경우에만 화면에 뿌리고, 401, 419, 601의 각 상황에 맞는 대처를 한다.

📦 기존 방식의 문제점

유저의 로그인 유효성 검사와 데이터 가져오기가 섞여있다.

• normal 페이지의 문제

  • 접속한 유저, 혹은 방문자가 해당 페이지의 owner가 아닌 경우에는 edit 버튼이 보여서는 안된다. 그러나 기존의 방식으로는 이것을 서버에서 체크해주지 않는다.
  • 데이터는 어떤 상황이든 주어져야하지만 유저의 로그인 정보는 필요한 상황

• 즉, normal 페이지에서 추가적으로 로그인 상태를 받을 필요가 있었다.

• 또한 normal 페이지와 edit 페이지에서 사용하는 위젯의 정보가 완전히 같은데, 각각 다른 요청 url로 데이터를 받아와야한다는 것이 논리적으로 느껴지지 않았다.

📦 문제점을 해결하기 위한 마라톤 회의

유저의 로그인 유효성 검사와 데이터 가져오기의 분리

• 기존
  • 요청 url을 페이지를 기준으로 나누고 데이터요청과 로그인 유효성 검사를 동시에 했다.
• 변경
  • 요청 url을 기능을 기준으로 구분했다.
  • 데이터요청 url과 로그인 유효성 검사요청 url로 나누었다.
  • 클라이언트에서는 페이지별로 필요한 요청을 하면 된다.

응답 형태의 변경

• 기존

{
  "success": bool,
  "data" : {},
  "message": string
}

• 변경

{
  "data": {},
  "message": string,
  "code": string
}

• message 예시: '위젯 편집 페이지에 다른 사용자가 들어갔습니다.
• code 예시: 'ok' | 'wrong_token' | 'expired_token' | 'unauthorized' | 'error'
• code는 'ok'가 아니어도 data가 올 수 있다.

📦 변경시 주의사항

원칙

스무스하고 불행이 적은 방향으로 프로세스를 짜야한다.

테스트는 아주 작은 단위로 한다.

기존, 변경 두가지 버전으로 운영하는 기간을 가진다.

새롭게 추가하는 코드는 변경된 방식으로 코드를 짜면 된다.

플로우

1. 기존 기능에 변화를 주는 것이 아니라 새로운 기능을 추가하는 방식으로 한다.
   • 기존에 작동하는 것을 망가뜨리면 안되기 때문이다.
2. 백엔드가 수정된 상태로 push를 함
3. 프론트가 백엔드 코드에 맞춰 수정
4. 백엔드에서 더 이상 필요 없어진 부분을 삭제한다.

---

• 기록해두면 도움이 될 것 같아서 변경하면서 변경 과정에 대한 것도 올려보려고 한다.