[Letter To Me] API 명세서 작성 완료 - 백엔드

▶API 명세서 작성

---

API 명세서 작성을 완료했다.

https://fortune-squash-ece.notion.site/Letter-To-Me-API-da31ec7fbd6143e2ade73ec6d4a8d893?pvs=4

[Letter To Me💌] API 명세서 노션 링크 | Notion

 

위 링크로 들어가면 API 명세서를 확인할 수 있다!

 

이번 포스팅에서는 API 명세서를 작성하면서 했던 고민들에 대해서 말해보려고한다.

 

 

 

▷열람이 가능한 편지 전체조회, 열람이 불가능한 편지 전체조회 API를 나눈 이유

---

편지 부분을 보면

열람 가능한 편지 전체 조회, 열람 불가능한 편지 전체 조회 API를 나눈걸 볼 수 있다.

 

"그냥 편지 전체조회 API를 하나만 만들어서 프론트에서 is_opende가 true인지, false인지로 필터링해서 화면에 출력해줘도 되지 않음?"

위 말처럼 할수도 있지만 서버에서 데이터를 분류해서 프론트한테 넘겨주면, 필요한 최소한의 정보만 받기 때문에 성능상 이득이 있다.

(네트워크 트래픽 감소, 응답 시간 단축, 클라이언트 리소스 절약 등등...)

굳이 데이터를 다 받아와서 클라이언트에서 분류하는건 비효율적일 것 같아서 이렇게 나누었다.

 

 

 

▷ 소셜로그인은 어떤 로직으로 동작하는거지...? API 명세서는 어떻게 짜지?

---

소셜로그인을 프로젝트에 적용해보는건 처음이다.

그래서 API 명세서를 어떻게 짜야할지 고민을 좀 했다.

 

우선 소셜로그인이 어떤식으로 흘러가는지 흐름을 파악했다.

아래는 찾아본 결과이다.

 

카카오나 네이버 같은 소셜로그인은

일반적인 의미에서 회원가입과 로그인을 통합한 형태로 동작하는 경우가 많다.

사용자가 처음 카카오나 네이버 로그인 버튼을 누르고 해당 소셜 계정으로 로그인할 때,

그 계정이 DB에 등록되어 있지 않다면, 해당 계정을 기반으로 회원가입을 처리하고,

그 계정이 DB에 등록되어 있다면, 로그인을 처리한다.

카카오나 네이버로 로그인하는 흐름을 알아보자.

1. 클라이언트에서 카카오 로그인 요청
   • 사용자가 클라이언트에서 “카카오 로그인” 버튼을 클릭
   • → 카카오의 OAuth 2.0 인증 페이지로 리다이렉트
2. 카카오 인증 서버에서 사용자 인증
   • 사용자는 카카오 로그인 페이지에서 카카오 계정으로 로그인
   • 카카오 로그인 성공 → 인증 서버는 클라이언트에게 authorization code(인가 코드)를 반환
   • authorization code(인가 코드)는 카카오 accessToken을 받기위해 사용됨.
3. 클라이언트에서 authorization code를 이용해 accessToken 요청
   • 클라이언트는 받은 authorization code를 이용해 카카오의 토큰 엔드포인트에 accessToken을 요청
   • 요청 성공 → 카카오는 클라이언트에게 accessToken(선택적으로 refeshToken도 추가로)을 반환
4. 클라이언트가 서버에 accessToken 전달

• 클라이언트는 카카오로부터 받은 accessToken을 우리의 API서버로 전달한다.
• 이 과정에서 클라이언트는 보통 accessToken을 담은 요청을 서버에 보내며, 이 요청의 형태는 JSON으로 되어 있음.

   5. 우리 서버에서 카카오의accessToken을 검증하고 사용자 정보 조회

• 우리의 API 서버는 카카오로부터 받은 accessToken을 이용해서 카카오 API에 사용자 정보를 요청.
• 서버는 이 accessToken을 사용하여 카카오 API에서 사용자의 고유 ID, 이메일, 닉네임 등의 정보를 가져옴.

   6. 우리 서버에서 사용자 로그인 또는 회원가입 처리

• 서버는 가져온 사용자 정보를 바탕으로 다음 중 하나를 수행
  • 회원가입 처리: 서버에 해당 카카오 ID로 등록된 사용자가 없을 경우, 새로운 사용자로 등록하고 로그인 처리
  • 로그인 처리: 서버에 해당 카카오 ID로 이미 등록된 사용자가 있을 경우, 해당 사용자로 로그인 처리

   7. 우리 서버에서 클라이언트에 JWT 토큰 반환

• 서버는 클라이언트에게 우리 서버가 발급한 accessToken과 refreshToken을 반환.

 

위 방식대로 흘러간다는걸 알았다.

 

그러면 백엔드는 각 소셜에서 준 클라이언트의 accessToken을 받아서 해당 토큰으로 사용자의 정보를 조회해서 로그인 또는 회원가입을 하면 된다는 것을 알았다.

 

따라서 로컬, 카카오, 네이버로 로그인 API를 분리해주었다.

 

 

 

 

 

 

▷ 회원가입 시 이메일 인증이랑 비밀번호 찾기 시 이메일 인증 API 분리

---

보안 쪽 API를 보면 회원가입 시 인증 코드 검증과 비밀번호 찾기 시 인증 코드 검증 API를 분리했다.

 

그 이유는 비밀번호 찾기를 하면

이메일 인증 -> 인증 확인 -> 비밀번호 변경

이런식으로 진행이 된다. 

 

하지만 로그인 된 상태에서 비밀번호 변경 시 Header에 AccessToken이 들어있어야 한다.

하지만 비밀번호 찾기로 비밀번호 변경으로 들어가면 Header에 AccessToken이 들어있을 수 없다.

 

따라서 회원가입 시 인증코드를 검증하는 API에서는 임시 토큰을 보내주지 않고,

비밀번호 찾기 시 인증코드 검증 API에서만 임시 토큰을 응답으로 보내줘서 비밀번호 변경이 가능하도록 했다.

 

하지만 여기서 주어지는 임시 토큰은 유지 시간이 굉장히 짧아야한다.

 

 

 

 

 

이렇게 API 명세서 작성을 완료했다.

아 추가로 프로필 이미지 업로드 API는 추후에 공부를 하면서 API 명세서를 작성 할 예정이다.

 

다음 포스팅은 API 개발로 돌아오겠다!