시리즈 설명

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

도입 이유

API 설계 원칙

• 모바일이든 웹이든 애플리케이션을 구성하는 서버가 있다면 클라이언트에서 요청을 보냈을 때 요청에 따른 응답 방법이 결정 되어 있어야 한다.
  API는 서버의 아키텍처에 기반하고 명확한 의사결정의 수단이 된다.
• '잘 디자인된' API는 불필요한 커뮤니케이션 비용을 줄일 수 있다고 한다.

직렬화 포맷

• 서버와 클라이언트는 분리 되어있고 서로 변할 수 있다.
  이런 과정에서 영향을 받지 않을수 있도록 데이터 표현에 대한 방식을 결정한다.

선택

API 설계 원칙

선택지

• REST API
• GraphQL

REST API 선택

• GraphQL은 프로젝트 팀원 중 아무도 사용해본 적이 없고, 공부해본 적이 없다.
  HTTP 위에서 돌아가는 우리 프로젝트에서 HTTP API말고 굳이 러닝 커브를 감수할 필요가 없다.
• REST API지만 사실 REST API에 대한 원칙을 모두 만족하지 못한다.
  REST API 방식을 기준으로 삼겠지만 구현은 HTTP 메소드에 따른 HTTP API와 Resource기반의 REST API가 되려는 RESTful API가 될 것이다.
• REST API는 모든 원칙을 지키기 매우 어렵다.
  왜 그런지는 당신이 구현한 건 REST API가 아니지만 괜찮아와 그런 REST API로 괜챃은가?를 보면 이해가 된다.

직렬화 포맷

자바 서버에서 작성된 Object 데이터는 swift 모바일 애플리케이션에서도
동일한 내용의 Object 데이터로 변환 할 수 있어야 한다.
이를 위해서 공통적인 데이터 표현 방식 즉 직렬화할 수 있도록 표준들이 존재한다.

선택지

• XML
• JSON
• Java Serializable

JSON 선택

• JSON은 애초에 간결하고 단독적으로 구성되기 위해 나온 방식이다.
  우리 프로젝트와 같이 웹이 연결될 수도 있고 앱이 연결될 수 있다면 유연성을 가장 잘 만족 시킨다.
• JSON은 라이브러리를 통해 객체를 바로 포맷팅이 가능하다.
  지원되는 자바 라이브러리는 Google의 GSON과 오픈소스 Jackson이 있다.
• XML은 트리구조로 문서화에 용이한 포맷팅 방식이다.
  다만 먼저 문서화가 되어야 하고 즉각적인 포맷팅이 어렵다.
  Maven도 이걸로 구성되어 있고, Spring Framework의 설정도 XML로 구성되어 있다. Spring Boot가 떠오르고 Gradle이 떠오르는 이유가 XML때문이라는 것을 생각해보면 XML은 당연히 기각이다.
• 자바 오브젝트를 굉장히 쉽게 바이트 코드로 변경 시켜주는 Java Serializable이 있지만 JVM에서밖에 동작하지 못한다 기각

지금까지 적용 사항

• 버전 관리 시스템 Git
• Git 호스팅 GitHub
• 이슈 트래커 Trello & Slack
• 개발 프로세스와 브랜치 전략 수립
• API 설계 원칙 - REST API
• 직렬화 포맷 - JSON