시리즈 설명

이 시리즈는 ab180의 PlanB(JoMinGyu)님이 작성하신 '백엔드가 이정도는 해줘야 함'을 토대로 프로젝트에 적용 시킨 것들입니다.

사전 결정 사항

• HTTP API + REST API를 통해 Resourceful API 스펙 결정
• JSON 직렬화 포맷 결정
• Authorization Header로 인증 정보 명시
• OAuth 2.0 Beare Authentication과 JWT 토큰을 이용한 인증 스키마

도입 이유

참고 글에 따르면 API 스펙 설계가 필요한 이유는

• 구조에 대한 고민
• API 스펙을 프론트엔드에게 전달 시 문서화 필요
• 실제 로직이 작성되지 않았으니 빠르게 수정 가능
• 문서화에 따른 커뮤니케이션 비용 절약

사전 준비 사항

• 기획서, 와이어프레임, UI 등의 기능명세서(물)이 나온 상태여야 한다.
• 플랫폼 API 개발 조직의 디자인 가이드를 참고

작업

API 스펙 설계

게시글 목록 API라면 페이지 개념이 들어갈 것인지, 페이지 당 게시글 갯수, 회원 가입 시 닉네임 중복 체크, 비밀번호의 최소/최대 자릿수, 비로그인 시 활동 상태 등 자세한 제약 사항도 스펙 설계의 단계에서 포함이 되어야 한다.

주의사항

• 입력/수정이 필요한 Form도 하나의 데이터다
• 서버는 버전 협상을 지원해야 한다
  API 서버의 경우 클라이언트가 항상 최신 버전이 가능하다는 생각이 아닌
  하위 호환성을 위한 버전 협상을 지원해야 한다

  HTTP Request Accept 헤더로 버전과 정보를 협상 가능

의문점

• API 서버는 플랫폼 종속적이지 않다
  그렇다면 API 서버는 클라이언트가 보내주는 정보로 각 환경을 파악하는건가?

  Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

iOS는 이런 식으로 리퀘스트헤더에 User-Agent를 보낼 수 있다는데 그럼 모든 사용자에게 이런 정보를 받는건가?
누가 처리해서 넘겨주지? 프록시?

지금까지 적용 사항

• 버전 관리 시스템 - Git
• Git 호스팅 - GitHub
• 이슈 트래커 - Trello & Slack
• 개발 프로세스와 브랜치 전략 수립 - 브랜치 분리에 따른 개발
• API 설계 원칙 - HTTP API + REST API = Resourceful API
• 직렬화 포맷 - JSON
• 인증 정보와 관리 - OAuth 2.0 Beare Authentication + JWT
• API 스펙 설계
• API 스펙 문서화