HTTP Method(REST API)

서버와 클라이언트간 통신을 할 때

HTTP Method를 이용하여 원하는 데이터를 주고 받거나, 요청을 처리한다.

REST API를 설계할 때 HTTP Method를 이용하여 설계하므로,

HTTP Method를 REST API로 정의하여 이야기 하겠다.

 

Rest API를 설계할 때,

URI를 이용하여 클라이트가 서버에게 요청을 보내고

데이터를 주고 받도록 되어있다.

 

URI가 뭘까?

URI(Uniform Resource Identifier)

앞 장에서 설명했듯이, URI는 Resource를 식별하기 위한 식별자이다.

그러므로, URI는 리소스만 식별해야 한다.

예를 들어, 클라이언트가 서버에게 회원을 등록해달라고 요청할 경우

회원이라는 개념자체가 Resource라고 할 수 있다.

즉, 요청에 대한 목적어가 Resource라고 정의할 수 있다.

등록하는 것은 동사이므로,

Resource 대상으로 하는 행위이지, Resource 자체로 볼 수 없다.

URI를 설계할 때는 Resource와 행위를 분리해야 한다.

예) 

• 리소스: 회원
• 행위: 조회, 등록, 삭제, 변경

 

아래는 REST API를 사용하기 위한 URI 설계 예이다

• 회원 목록 조회: /members
• 회원 조회: /members/{id}
• 회원 등록: /members/{id}
• 회원 수정: /members/{id}
• 회원 삭제: /members/{id}

* 계층 구조상 상위 Resource를 컬렉션으로 보고 복수단어 사용 권장(member -> members)

 

REST API의 대표적인 메소드는 아래와 같다

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

 

아래에서 REST API 메소드에 대한 상세설명을 하겠다

 

1. GET

• Resource를 조회할 때 사용
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달 예) GET /search?q=hello&hl=ko HTTP/1.1
• HTTP 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
• 전달하고 싶은 데이터는 query를 통해서 전달하는 게 일반적

 

2. POST

• 클라이언트의 요청 데이터를 처리할 때 사용(예. 로그인, 회원가입)
• 서버에게 보낼 데이터를 HTTP 메세지 바디에 담아 전달

• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• 이외에도, 다른 메소드로 처리하기 어려운 경우에 사용 

          예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

 

 

3. PUT

• 기존 Resource 수정에 사용됨
• 기존 Resource가 존재할 경우 새로운 Resource로 대체

• 부분적 대체가 아닌 모든 Field 대체(예. username이나 age 하나만 대체 불가)
• Field 누락 시, 해당 필드는 삭제됨 
• 기존 데이터가 없을 경우 새로운 Resource 생성클라이언트가 Resource 위치를 알고 URI 지정 

• POST와 차이점(POST는 새로운 Resource를 생성하기 위한 메소드이므로 기존 Resource의 위치를 몰라도 된다)

 

3. PATCH

• Resource의 부분 수정에 사용
• Resource의 일부 Field만 수정가능

 

 

4. DELETE

• Resource를 제거할 때 사용

• 제거하고자 하는 Resource가 존재할 경우에만 제거됨

 

 

아래는 HTTP Method의 속성에 대한 설명이다

 

HTTP Method의 속성은 다음과 같이 존재한다.

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

 

위 속성에 대한 설명은 아래와 같다.

 

1. 안전(Safe Methods)

• 호출해도 리소스를 변경하지 않는 성질
• GET이 대표적
• 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하는 경우는 고려하지 않음
• 해당 리소스만 고려한다.

 

2. 멱등(Idempotent Methods)

• f(f(x)) = f(x)
• 동일한 요청에 대해, 몇 번을 호출하든 동일한 결과를 내는 메소드
• 멱등 메서드
  • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
  • POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다(새로고침 시, 중복된 결제 발생)
• 자동 복구 메커니즘에 사용 예)서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 재요청 하는 경우
• 만약 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
  • 사용자1: GET -> username:A, age:20
  • 사용자2: PUT -> username:A, age:30
  • 사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회
• 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

 

3. 캐시가능(Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• 동일한 요청에 대한 응답 결과를 저장해놓음
• GET, HEAD, POST, PATCH 캐시가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 HTTP Message Body 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음