HTTP - HTTP API 설계 예시

HTTP API 설계 예시

• HTTP API - 컬렉션
  • POST 기반 등록
  • 예 : 회원 관리 API 제공
• HTTP API - 스토어
  • PUT 기반 등록
  • 예 : 정적 컨텐츠 관리, 원격 파일 관리
• HTML FORM 사용
  • 웹 페이지 회원 관리
  • GET, POST만 지원

회원 관리 시스템 API 설계 - POST 기반 등록

리소스를 식별하는 URI는 리소스를 식별해야 한다.
리소스가 아닌 다른 것은 식별하면 안 된다.

• 회원 목록
  • /members -> GET
  • 정렬이나 조건 검색이 필요하면 쿼리 파라미터를 이용하자.
• 회원 등록
  • /members -> POST
• 회원 조회
  • /members/{id} -> GET
• 회원 수정
  • /members/{id} -> PATCH, PUT, POST
  • PATCH는 부분적으로 수정이 가능하지만,PUT은 기존 리소스를 삭제하고 덮어버리는 작업을 하기 때문에 수정 작업에서는 PATCH를 사용하는 것이 개념적으로 좋다.
    • 클라이언트에서 아예 완전히 덮어도 되는 상황이라면 PUT을 사용해도 무방하지만 이런 경우는 게시판에서 글(혹은 댓글)을 수정하는 경우가 아니면 흔하지 않다.
  • 어중간하면 POST를 사용하자!
• 회원 삭제
  • /members/{id} -> DELETE

회원 관리 시스템 POST - 신규 자원 등록 특징

POST로 생성할 때는 서버에서 리소스 URI를 결정하고 만들어준다.
이런 형식을 컬렉션(Collection)이라 한다.

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

파일 관리 시스템 API 설계 - PUT 기반 등록

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

파일 관리 시스템 PUT - 신규 자원 등록 특징

PUT을 통해 생성할 때는 클라이언트에서 URI를 결정하고 만들어준다.
이런 형식을 스토어(Store)라고 한다.

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

참고

대부분 POST를 사용하고 PUT은 사용하는 비중이 거의 없다.

HTML FORM 사용

• HTML FORM은 GET, POST만 지원
• AJAX같은 기술을 사용해서 해결 가능
• 여기서는 순수 HTML, HTML FORM을 이야기 한다.
• GET, POST만 지원하므로 제약이 있다.

HTML FORM 사용 URI

• 회원 목록
  • /members -> GET
• 회원 등록 폼
  • /members/new -> GET
• 회원 등록
  • /members/new, /members -> POST
    • 실무 팁: 회원 등록 폼(GET)과 동일한 URI를 사용해서 오류가 발생했을 때 다시 form 페이지로 전환하기 편하게 구성 가능
• 회원 조회
  • /members/{id} -> GET
• 회원 수정 폼
  • /members/{id}/edit -> GET
• 회원 수정
  • /members/{id}/edit, /members/{id} -> POST
• 회원 삭제
  • /members/{id}/delete -> POST
  • GET, POST만 지원하기 때문에 컨트롤 URI(여기서는 delete)를 사용해야 함.

컨트롤 URI

HTML FORM은 GET, POST만 지원하기 때문에 컨트롤 URI를 사용해야 한다.

• 컨트롤 URI
  • GET, POST만 지원하므로 제약이 있다.
  • 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
  • POST의 /new, /edit, /delete가 컨트롤 URI
  • HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)

정리

• HTTP API - 컬렉션
  • POST 기반 등록
  • 서버가 리소스 URI 결정
• HTTP API - 스토어
  • PUT 기반 등록
  • 클라이언트가 리소스 URI 결정
• HTML FORM 사용
  • 순수 HTML + HTMl form 사용
  • GET, POST만 지원
    • 때문에 컨트롤 URI 사용

참고하면 좋은 URI 설계 개념

• 문서(document)
  • 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
  • 예 : /members/100, /files/star.jpg
• 컬렉션(collection)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리
  • 예 : /members
• 스토어(store)
  • 클라이언트가 관리하는 자원 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 예 : /files
• 컨트롤러(controller), 컨트롤 URI
  • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  • 동사를 직접 사용
  • 예 : /members/{id}/delete
  • 24 03 11 추가
    • 실무에서 복잡한 상황에서의 설계 시 부득이하게 무조건 사용해야 함
    • 단, 가급적이면 문서(document), 컬렉션(collection), 스토어(store)로 해결하자.

인프런 김영한 지식 공유자님의 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식