• 부트캠프 상세내용은 아래 링크[1] 참고.

저번에 당근 마켓의 데이터베이스를 모델링하고 실제로 만들어봤다. 이제 만든 데이터베이스를 토대로 API를 설계하고 만들어 보려고 한다. API 명세서를 먼저 만들어야 하는데, 어떤 내용들을 넣을지 빠르게 생각해봐야겠다.

📖 강의 주제

- Backend Language & REST API

Backend Language, HTTP 메소드, 패킷 및 API 구조 이해

---

📝 목표

- API 설계

• API 개념 모델링
• API 목록

- API 개발

• Node.js와 Express
• Postman

---

▶️ 개발 일지

1. 강의 내용 정리

1) ERD 설계 참고

• PK(기본키)는 VARCHAR나 다른 타입도 가능하지만 대체적으로 INT나 BIGINT를 사용하여 쉽게 구분 가능하도록 한다.
• 문자열 데이터의 최대 길이 산출이 어려울 때는 TEXT 타입을 사용한다. 주로 이미지 URL이나 비밀번호에 많이 사용한다.
• 위치 정보를 불러올 때는 데이터를 제공해주는 API의 명세를 참고해서 컬럼 타입을 정한다.
• 글의 성격에 대한 테이블과 상세 내용에 대한 테이블은 분리하는 것이 일반적이다.
• 현재 로그인 된 사용자의 정보를 확인하여 기능 및 설정 권한 (데이터 접근 권한)을 부여한다.

2) 패킷

• 패킷이란 서버와 클라이언트간 주고받는 데이터
• 패킷은 크게 Header와 Body로 구분된다.
• Header : 인증 정보, 사용자 정보 등의 메타 데이터(데이터의 정보를 기술하는 데이터)
• Body: 요청 및 응답에 대한 데이터

3) HTTP

• 인터넷 통신 규약(프로토콜) 중 하나
• 데이터를 주고받는 데 사용되는 방법론이며 현대 인터넷에서 가장 많이 쓰이고 있다.
• HTTP 메세지를 사용해서 서버와 클라이언트에 요청 및 응답을 하고, 요청은 주로 클라이언트에서 서버로 보낼 때 사용된다.
• HTTP의 구조는 시작줄, Header, Body로 나뉜다.
  시작줄에는 요청 메소드와 URL이 있고, Header에는 추가 정보들, Body에는 본문이 들어있다.

4) API

• 기계와 기계, 프로그램과 프로그램끼리 통신하기 위해서 필요한 인터페이스
• 데이터베이스와 프로그래밍 언어 사이의 중간 다리 역할을 하는 것도 API다
• 웹에서 많이 쓰이는 API 중 HTTP 메세지에 대한 내용을 동사(POST, GET, PUT, DELETE 등 )로 표현한 것이 REST API다

2. API 설계

1) API 개념 모델링

• API를 개발하기 전에 어떤 내용과 방식으로 클라이언트에게 데이터를 전달할지 생각해봐야 한다. 클라이언트는 DB의 구조를 몰라도 원하는 데이터를 요청할 때, 서버가 알맞게 데이터를 선별해서 전달해야 한다.
• 실제로 일할 때는 프론트엔드 부서와 백엔드 부서간 협의 하에 API를 정리하겠지만, 지금은 나 혼자 작업하는 거니까 약간의 상상을 가미해서 API를 모델링 해봤다. 실제 어플과는 상당히 다를 수 있음 주의! 🤷🏻‍
• 먼저 크게 3가지 테이블 위주로 클라이언트에서 데이터를 요청하는 것을 생각해봤다. 생각한 것은 이것보다 더 많지만, 가장 핵심 데이터들로 최소화 시켰다. 이제 이 모델링을 토대로 API 목록을 만들어보자.
  

2) SOAP vs REST API

• API 목록을 작성하기 전에 대체 REST API는 어떻게 생겨먹은 것이고, 이것 말고 다른 API는 있는지 찾아봤다. API라는게 특정 언어나 소스로 지정된 것이 아니라, 서버와 클라이언트 간의 약속이다 보니 많은 종류가 있고 그 중에서 대표적으로 쓰이는 것이 SOAP랑 REST인 것을 알았다.
• 엄밀히 따지면 SOAP와 REST는 본질적으로 다른 기술이다. SOAP는 HTTP, FTP, SSH와 같은 프로토콜이고 REST는 HTTP의 아키텍쳐 스타일이다.
• SOAP(Simple Object Access Protocol)는 그 자체로 보안 프로토콜이며, 보안이나 메세지 전송 등에 있어 REST보다 더 복잡하다. WS-Security라는 자체 표준 보안 기능도 있어 주로 은행용 서버처럼 보안 수준이 높을 필요가 있는 곳에서 쓰인다.
• REST(Representational State Transfer)는 네트워크를 통해서 클라이언트와 서버 간 통신을 하게 해주는 아키텍쳐 스타일이며, 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 한다. 단순함이 핵심이며 데이터 포맷은 JSON을 사용하여 브라우저 간 호환성이 좋다.
• 아래 내용은 위시캣 블로그[2]에서 가져온 SOAP와 REST의 비교 자료다.
  

3) API 목록

• 지난번에 ERD와 데이터베이스 설계한 것을 기본으로 API 목록들을 작성했다. REST API로 작성했고 path variable과 query string을 적절히 이용해서 계층을 나눴다.
• PUT과 PATCH는 내용을 수정하는 API로 FK를 포함하고 있는지 여부에 따라서 구분했다. FK가 없으면 나머지 데이터가 Null이나 Default로 설정해도 된다고 생각했다.
• (추가) API를 설계할 때 사용자 관점과 관리자 관점에서 요청하는 데이터를 구분해야 한다. 나는 두 상황을 모두 고려해서 API를 작성했는데 그러다보니 API 목록이 무려 100개나 넘게 만들어지는 불상사가 발생했다...😩
  
• path variable과 query string을 구분하는 기준은 블로그[3] 내용을 참고했다. 핵심은 리소스를 식별하고 싶을 때 path variable을, 정렬이나 필터링을 할 때는 query string을 사용하는 것이다.

API 목록은 작성하거나 실제 개발하다가 수정한 부분이 많았다. 처음에 너무 프론트엔드를 배려(?)해서 상세하게 API를 구분한 것 때문에 목록이 너무 많이 늘어난 부분도 있었고, 수정과 삭제를 한 API에 담으려고 한 것 때문에 다시 분리한 것도 있었다.
이 다음에는 작성한 API 목록을 토대로 Node.js와 Express로 실제 개발을 진행할 것이다.

& 링크모음

[1] : 라이징캠프
[2] : SOAR REST 차이, 두 방식의 가장 큰 차이점은?
[3] : Path Variable과 Query Parameter는 언제 사용해야 할까?