HTTP - HTTP API, GET&POST

HTTP API를 만들어보자.

• 요구사항 / API URI 설계
  • 회원 목록 조회 /read-member-list
  • 회원 조회 /read-member-by-id
  • 회원 등록 /create-member
  • 회원 수정 /update-member
  • 회원 삭제 /delete-member

위 설계는 좋은 URI 설계일까?
URI 설계에서 가장 중요한 것은 리소스 식별이다.

API URI(Uniform Resource Identifier)

• 리소스란?
  • 회원을 등록하고 수정하고 조회하는 것이 리소스가 아니다.
  • 회원이라는 개념 자체가 리소스다.
• 리소스는 어떻게 식별하는 것이 좋은가?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 됨.

수정된 설계

• 요구사항 / API URI 설계
  • 회원 목록 조회 /members
  • 회원 조회 /members/{id}
  • 회원 등록 /members/{id}
  • 회원 수정 /members/{id}
  • 회원 삭제 /members/{id}

리소스로 구분을 하니 모든 메소드가 구분이 되지 않는 문제가 발생한다.
리소스를 식별하면 행위를 분리해서 설계하자!

리소스와 행위 분리

가장 중요한 것은 리소스를 식별하는 것이다.

• URI는 리소스만 식별
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • 리소스 : 회원(members)
  • 행위 : 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사(미네랄(리소스)을 캐라(행위))

HTTP 메소드 - GET, POST

• 주요 메소드
  • GET : 리소스 조회
  • POST : 요청 데이터 처리, 주로 등록에 사용한다.
  • PUT : 리소스를 대체, 해당 리소스가 없으면 생성한다.
  • PATCH : 리소스 부분 변경
  • DELETE : 리소스 삭제
• 기타 메소드
  • HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메소드)을 설명(주로 CORS에서 사용)
  • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 진행

GET

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

GET 예시

요청 메시지

GET /members/100 HTTP/1.1
Host: localhost:8080

데이터

{
  "username": "young",
  "age": 20
}

응답 데이터

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34

{
  "username": "young",
  "age": 20
}

1. 조회를 위해 클라이언트에서 서버로 요청 메시지를 전달한다.
2. 요청 메시지가 서버에 도착
3. 요청한 클라이언트에 응답하기 위해 데이터를 응답 데이터로 만들어 응답한다.

POST

POST /members HTTP/1.1
Content-Type: application/json

{
  "username": "hello",
  "age": 20
}

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

POST 예시

메시지

POST /members
HTTP/1.1 Content-Type: application/json
{
  "username": "young",
  "age": 20
}

데이터

{
  "username": "young",
  "age": 20
}

응답 데이터

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100

{
  "username": "young",
  "age": 20
}

1. 클라이언트에서 서버로 POST 메소드로 메시지를 전달한다.
2. 메시지를 전달 받은 서버는 신규 리소스 식별자(/members/100)를 생성해서 데이터를 등록한다.
3. 서버는 클라이언트로 응답 데이터를 보내 결과를 응답한다.

POST는 요청 메시지를 어떻게 처리할까?

• 스펙 : POST는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.
• 예시
  • HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
    • 예 : HTML FORM에 입력한 정보로 회원가입, 주문 등에 사용
  • 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
    • 예 : 게시판 글쓰기, 댓글 달기
  • 서버가 아직 식별하지 않는 새 리소스 생성
    • 예 : 신규 주문 생성
  • 기존 자원에 데이터 추가
    • 예 : 한 문서 끝에 내용 추가하기
• 정리
  • 리소스 URI에 POST 요청에 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.
    • 정해진 것이 없다!

POST 정리

• 새 리소스 생성(등록)
  • 서버가 아직 식별하지 않은 새 리소스 생성
• 요청 데이터 처리
  • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
    • 예 : 주문에서 결제 완료 -> 배달 시작 -> 배달 완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
  • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
• 다른 메소드로 처리하기 애매한 경우
  • 예 : JSON으로 조회 데이터를 넘겨야 하는데, GET 메소드를 사용하기 어려운 경우

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