04. HTTP 웹 기본 지식 - HTTP API

2021.05.03 - [BASIC] - 01. HTTP 웹 기본 지식 - 인터넷 네트워크

2021.05.03 - [BASIC] - 02. HTTP 웹 기본 지식 - URI

2021.05.03 - [BASIC] - 03. HTTP 웹 기본 지식 - 모든것이 HTTP

 

API URI 고민

리소스라는 의미는 뭘까?

회원을 등록하고 수정,조회 하는게 리소스는 아니다

회원이라는 개념 자체가 바로 리소스이다. 나는 DB에 저장되어있는 한 로우의 데이터라고 이해한다.

그렇다면 어떻게 식별하는게 좋을까?

수정,조회 하는 것을 모두 배제하고 회원이라는 리소스만 식별한다.

-> 회원 리소스를 URI 매핑

 

API URI 설계

- 리소스만을 식별하기 때문에 URI 계층 구조를 활용한다.

- 리소스와해당 리소스를 대상으로 하는 행위를 분리한다.

- 여기서 리소스(명사)는 회원을 뜻하고 

- 행위(동사)는 조회, 등록, 삭제, 변경을 뜻한다.

 

예)

회원 목록 조회 /members

해당 회원 조회 /members/{id}

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

 

HTTP 메서드 종류

 

GET 리소스 조회

서버에 전달하고 싶은 데이터를 query를 통해 전달한다.

메시지 body를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많다.

 

POST 요청 데이터 처리, 주로 등록에 사용

메시지 바디를 통해 서버로 요청 데이터를 전달한다.

서버는 요청 데이터를 처리한다. 주로 전달된 데이터를 신규 리소스 등록, 프로세스 처리에 사용한다.

201 Created를 보내면서 (200 Ok 도 무관) 자원이 생성된 URI를 return 해준다. -> 나중에 프로젝트할때 확인해봐도 좋을것 같다

 

PUT 리소스를 대체, 해당 리소스가 없으면 생성

리소스를 완전히 대체한다.

리소스가 == null ? 생성 : 대체

만약 값이 같아도 필드 갯수가 다르다면 요청하는 값 그대로 덮어쓰기한다.

클라이언트가 구체적인 리소스 위치를 알고 지정한다.

 

PATCH 리소스 부분 변경

그렇다면 회원 수정 일 때 PATCH를 사용하는게 맞을까? 여태 PUT으로 알고 있었다.

PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있다. 또한 PUT의 경우는 멱등하지만, PATCH의 경우는 멱등하지 않다. PUT은 전체 자원을 업데이트 하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리된다. 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.
출처: https://javaplant.tistory.com/18 [자바공작소]

 

DELETE 리소스 삭제

HEAD GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

OPTIONS 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (CORS 에서 사용)

CORS (Cross-Origin Resource Sharing)이 뭐지?

자원 요청 출처를 확인하는 건데 자세한 내용은 아래 블로그에 엄청 자세하게 나와있다!

evan-moon.github.io/2020/05/21/about-cors/

 

CONNECT 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행(거의 사용하지 않음)

 

 

HTTP 메서드의 속성

 

- 안전(Safe Method)

호출해도 리소스를 변경하지 않는다.

 

- 멱등(Idempotent)

한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

GET : 몇번 조회하든 같은 결과가 조회된다.

PUT : 결과를 대첼한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.

DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

POST : 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.

 

멱등의 활용 : 자동 복구 메커니즘 -> 멱등이 가능한 METHOD에서 에러가 생겼을 때 자동으로 재요청할 수 있다.

 

- 캐시가능(Cashable)

이미 받은 파일을 다시 받지 않도록 localPC 웹브라우저 내부에 저장한다.(캐시 한다.)

 

GET, HEAD ,POST, PATCH가 캐시 가능하다.

실무에서는 GET,HEAD 정도만 캐시로 사용한다. POST, PATCH는 본문 내용까지 캐시 키 로 고려해야 하는데 구현이 쉽지 않다.