API 설계

✅ 김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 공부하며 정리한 글입니다.

두 가지 중요한 개념

1. Resource - URI와 연결
2. 행위 - method와 연결

Resource

• URI (Uniform Resource Identifier)
  - 리소스만 식별하면 된다!
  

행위

CRUD: Create, Read, Update, Delete

• HTTP method: GET, POST, PUT, PATCH, DELETE
  - GET: 조회
  - POST: 요청 데이터 처리, 데이터 등록 등
  - PUT: 대체
  - PATCH: 부분 변경
  - DELETE: 삭제

GET

• request: 전달하고 싶은 데이터는 쿼리 파라메터로 전달
• 조회

POST

• request: 메시지 바디를 통해 요청 데이터 전달

1. 신규 리소스 등록
2. 메시지 바디로 들어온 데이터를 처리
3. 그 외 어떻게 처리할지 애매하다?! POST 사용

PUT

• 리소스가 있으면 대체, 없으면 생성
• 클라이언트가 리소스를 식별한다는 특징이 있음
• request: 메시지 바디를 통해 요청 데이터 전달
  - POST, PUT, PATCH 공통

HTTP 메소드 활용

클라이언트에서 서버로 데이터 전송 시;
1. 정적 데이터 조회 - 리소스 경로
2. 동적 데이터 조회 - 쿼리 파라메터 사용
3. HTML Form을 통한 데이터 전송
4. HTTP API를 통한 데이터 전송

HTML Form을 통한 데이터 전송

• GET, POST만 지원
• Content-Type: application/x-www-form-encoded, multipart/form-data
  - multipart/form-data는 여러 파일과 폼의 내용 함께 전송 가능하다!

HTTP API를 통한 데이터 전송

• 서버 to 서버, 앱/웹 클라이언트
• Content-Type: application/json 주로 사용

HTTP API 설계 분류

1. HTTP API - 컬렉션
   • POST 기반 등록
2. HTTP API - 스토어
   • PUT 기반 등록
3. HTML Form 사용

HTTP API - 컬렉션

• 컬렉션: 서버가 관리하는 리소스 디렉터리로, 서버가 리소스의 URI를 생성하고 관리
• ex. 회원 등록: /members
  - 이때 클라이언트는 등록될 리소스의 URI를 모르고, 서버가 생성함
  • /members/100

HTTP API - 스토어

• 스토어: 클라이언트가 관리하는 자원 저장소로, 클라이언트가 리소스의 URI를 알고 관리
• ex. 파일 시스템 관리: PUT, /files/start.jpg

컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용한다는 특징
• ex. /members/{id}/delete

👀 문서? 단일 개념 -> 파일 하나, 객체 인스턴스, 데이터베이스 row

✅ 정리

컬렉션, 문서, 스토어로 최대한 해결하되, 이것만으로 해결하기 힘들면 컨트롤 URI를 사용한다!