[HTTP] API 설계 예시

좋은 HTTP API 설계에 대해서 알아본다.

• HTTP API - 컬렉션

  • POST 기반 등록(회원 관리 API 등)

• HTTP API - 스토어

  • PUT 기반 등록(정적 컨텐츠 관리, 원격 파일 관리)

• HTML FORM 사용

  • 웹 페이지 회원 관리(GET, POST만 지원)

차량 관리 시스템

---

아래는 차량 관리 시스템의 API 설계다. (POST 기반 등록)

• 차량 목록 /cars -> GET
• 차량 등록 /cars -> POST
• 차량 조회 /cars/{id} -> GET
• 차량 수정 /cars/{id} -> PATCH, PUT, POST
• 차량 삭제 /cars/{id} -> DELETE

POST 기반의 신규 자원(resource)은 다음과 같은 특징을 가진다.

• 클라이언트는 등록될 리소스의 URI를 모른다.
• 서버가 새로 등록된 리소스의 URI를 생성해준다.
  • HTTP/1.1 201 Created
    Location: /cars/100
• 컬렉션(Collection)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리
  • 여기서 컬렉션은 /cars

---

파일 관리 시스템

---

아래는 파일 관리 시스템의 API 설계다. (PUT 기반 등록)

• 파일 목록 /files -> GET
• 파일 조회 /files/{filename} -> GET
• 파일 등록 /files/{filename} -> PUT
• 파일 삭제 /files/{filename} -> DELETE
• 파일 대량 등록 /files -> POST

PUT 기반의 신규 자원(resource)는 다음과 같은 특징을 가진다.

• 클라이언트가 리소스 URI를 알고 있어야 한다.
  • 파일 등록 /files/{filename} -> PUT
  • PUT /files/car.jpg
• 클라이언트가 직접 리소스의 URI를 지정한다.
• 스토어(Store)
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 RUI를 알고 관리
  • 위의 예제에서 스토어는 /files

---

HTML FORM 사용

---

HTML Form은 GET과 POST만 지원한다.
이러한 점을 보완하기 위해 컨트롤 URI를 사용한다.
컨트롤 URI의 특징은 아래와 같다.

• GET과 POST만 사용 가능하기 때문에 이러한 제약을 해결하기 위해 동사로 된 리소스 경로 사용
• 실제 리소스의 앞, 뒤에 존재하는 동사가 컨트롤 URI
• HTTP 메서드로 해결하기 애매한 경우 사용

아래는 HTML FORM과 컨트롤 URI를 사용하여 작성한 API 설계다.

• 차량 목록 /cars -> GET
• 차량 등록 폼 /cars/new -> GET
• 차량 등록 /cars/new, /cars -> POST
• 차량 조회 /cars/{id} -> GET
• 차량 수정 폼 /cars/{id}/edit -> GET
• 차량 수정 /cars/{id}/edit, /cars/{id} -> POST
• 차량 삭제 /cars/{id}/delete -> POST

---

마지막으로 좋은 URI 설계를 위한 개념에 대해서 정리하고 마무리한다.

• 문서(Document)

  • 단일 개념(파일 하나, 객체 인스턴스, DB row)
  • 예) /cars/100, /images/car.jpg

• 컬렉션(Collection)

  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리

• 스토어(Store)

  • 클라이언트가 관리하는 자원 저장소
  • 클라이언트가 리소스의 URI를 미리 알고 관리

• 컨트롤러(Controller), 컨트롤 URI

  • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  • 직접적인 동사를 사용