[네트워크] HTTP Method(GET, POST, PUT, DELETE, PATCH, HEAD)와 Method의 속성

상황

 

HTTP API를 만들어보는 과제가 주어졌다하자. 

회원정보관리 API 만든다고 하면 

목록조회, 개인조회, 회원 등록, 회원정보 수정, 회원 삭제 등의 기능이 필요하다.

 

여기서 URI 설계를 할때 고민이 생기는데 이는 Resource를 주로 설계해야 한다.

 

What is Resource?

• 회원등록, 수정 이런건 리소스가 아니다.
• 회원자체가 리소스!

 

리소스는 어떻게 식별할까?

• 행위를 보지말기: 회원등록, 수정, 조회 등 모두 URI에서 배제: HTTP 메소드가 행위를 구분해준다.
• 회원 리소스를 URI에 매핑한다.

 

API URI 설계

• 리소스 식별
• URI 계층 구조를 활용

 

 

 

HTTP 메서드 : 주요 메서드 정리

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

 

기타 메서드

• HEAD : GET과 동일하지만 메세지 부분을 제외하고 상태 줄과 헤더만 반환한다.
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명한다(주로 CORS에서 사용)
• 밑에는(Connect, Trace) 거의 사용안함
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행한다.

 

 

1. GET : 리소스 조회

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

 

순서

1. 메세지 전달 : 쿼리스트링에 넣어서 전달
2. 서버 도착
3. 응답 데이터 : JSON같은 메세지를 만들어서 클라이언트에 보냄

 

2. POST : 

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

 

순서

1. 리소스 등록 : 메세지 전달(필요데이터전달)
2. 서버가 신규리소스 식별자 생성
3. 응답데이터 : Location 을 써줌, 자원데이터도 보냄

POST : 요청데이터를 어떻게 처리한다는 뜻일까?

대상 리소스가 리소스의 고유한 의미체계에 따라 요청에 포함된 표현을 처리하도록 요청

 

정리

1. 새 리소스 생성(등록)
2. 요청 데이터 처리

• 프로세스를 처리해야 하는 경우
• POST 결과로 새로운 리소스가 생성되지 않을 수도 있다!! → 동사로 Control URI

3. 다른 메서드로 처리하기 애매한 경우

• JSON으로 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우
• 애매하면 POST

 

 

3. PUT

• 리소스를 대체하는 것
• ex. 파일복사하기와 같음) 폴더에 파일이 없다면 생성하고 기존의 파일이 있다면 원하는대로 덮어버리는 것; 완전히 대체하는 것
• 클라이언트가 리소스를 식별한다.
• 클라이언트가 리소스 전체 위치를 알고 URI를 지정: POST 와 차이점

 

주의점

• 기존에 저장되어 있던 다른 데이터를 덮어서 없애버릴 수 있다: 리소스 수정이 아니기 때문 → 패치를 쓰면 된다.

 

4. PATCH

• PATCH 로 보내면 부분변경(기존에 있던 데이터가 남아있어 원하는 부분만 변경)이 된다.
• 안되는경우, POST를 쓰면 된다.

 

5. DELETE

• 삭제

 

 

Method 속성

1. Safe

2. Idempotent

3. Cacheable

 

1) Safe

• 호출해도 리소스를 변경하지 않는다
• POST, PATCH, DELETE 이런거 호출했을때 변경일어나면 안전하지 않은것.
• GET, HEAD(바디부분만 뺀거) : 안전

Q. 호출해서 로그쌓여서 터져서 장애가 발생하면?

• 안전은 해당 리소스만 고려하는것
• 리소스 변경이 안되기 때문에 안전한 것

2) Idempotent(멱등)

• 호출을 몇번이나 해도 결과가 똑같다.
• 멱등 메서드
• GET, PUT, DELETE 3가지

• GET : 200번 호출해도 결과가 같다.
• PUT : 최종결과물이 똑같다.
• DELETE : 삭제의 결과가 똑같다.
• POST : 멱등이 아니다~~~//결제 : 중복결제

자동복구메커니즘에 쓸 수 있다.

 

 

예외

• 재요청 중간에 다른 곳에서 리소스를 변경해봄
• 외부요인으로 중간에 리소스가 변경되는 것까지 고려하지 않음 : 멱등하지 않다고 생각

 

3) Cacheable(캐시가능)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD는 캐시로 사용하지만 POST, PATCH 사용가능하지만
  본문내용까지 캐시키로 고려해야하는데 구현이 쉽지 않아서 사용안함