HTTP 메서드

✨ API URI 설계 방법 

(URI : Uniform Resource Identifier)

회원을 조회하고, 등록, 수정, 삭제하는 api를 설계해보자. 

 

예시)

• 회원 목록 조회 /read-member-list
• 회원 등록 /create-member
• 회원 수정  /update-member
• 회원 삭제  /delete-member

위의 방식은 직관적이다. 이처럼 설계할 수도 있지만, 좋은 URI는 이런 방식을 사용하지 않는다. 

 

 

api를 설계할 때 가장 중요한 것은 리소스 식별이다. 

위의 예제에서 회원을 등록하고 수정, 조회하는 것은 리소스가 아니며, 회원이라는 개념 자체가 리소스이다.

ex) 미네랄을 캐라 -> 미네랄이 리소스

 

따라서 리소스를 식별하여 설계할 때에는, 회원을 등록하고 수정, 조회하는 것은 모두 배제하고, 회원이라는 리소스만 식별해준다. (회원 리소스를 URI에 매핑해준다.)

 

 

설계시 리소스와 행위를 분리해서 작성해주면 된다. 

 

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

리소스는 명사, 행위는 동사이다. 

 

 

🙆 올바른 api 설계 : 리소스를 식별하여 행위와 분리해주고, URI 계층 구조를 활용한다. 

 

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

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

위의 api는 메서드로 구분을 해준다. 

✨ HTTP 메서드 종류

http 메서드 : client가 서버에 요청할 때, 기대하는 행동

• GET : 리소스 조회
• POST : 요청 데이터 처리(주로 등록시에 사용한다)
• PUT : 리소스를 대체(덮어쓰며)하며, 해당 리소스가 없으면 새로 생성해준다.
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

 

1. GET

  주로 리소스를 조회할 때 사용된다. (회원 정보를 조회, 목록보기)

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

 

클라이언트가 메시지 전달

 

 

서버가 /members/100으로 가서 클라이언트가 요청한 데이터를 확인한다. 

 

 

 

서버는 데이터를 확인하고, 클라이언트에게 응답 데이터를 보내준다. 

 

 

 

 

2. POST (무적)

  POST는 메시지 바디를 통해 서버로 들어온 데이터를 처리하는 모든 기능을 사용한다. 
  데이터를 전달해 신규 리소스로 등록하거나, 약속된 프로세스를 처리하는데 사용된다. 

 

 

3. PUT

  리소스를 완전히 대체한다. 해당 리소스가 없으면 새로 리소스를 생성해준다. 

  (파일 덮어쓰기처럼 동작한다.)

 

  POST와의 중요한 차이점은, PUT에서는 클라이언트가 리소스를 식별한다는 점이다. 

 

PUT메소드로 클라이언트가 요청한다. 

클라이언트는 해당 resource 경로를 알고있다.

(/members/100) 클라이언트가 리소스 위치를 알고 URI를 지정한다!

 

 

POST메소드는 클라이언트가 리소스의 위치를 모른다. 

 

 

 

PUT은 리소스를 완전히 대체하기에 정보 일부를 수정하는게 어렵다. 

이름, 나이의 데이터가 있을 때, 나이만 바꿔서 클라이언트가 요청하면, PUT은 나이값만 업데이트시키는 것이 아니라,

기존의 '이름-나이'의 데이터 위에 나이의 데이터만 넣어, 결과적으로 이름의 데이터가 사라지게 된다. 

리소스 부분 변경시에는 PUT을 사용하지 않는다. 

 

4. PATCH

리소스 부분 변경시에는 주로 PATCH메소드를 사용한다. 

수정을 원하는 부분만 수정하여 서버에 전달해주면 된다. 

간혹 버전 상의 문제로 PATCH를 지원하지 않는 경우에는 POST를 사용하기도 한다. 

 

5. DELETE

 

리소스를 삭제하는데 사용된다. 

 

✨ HTTP 메서드 속성

1. 안전 : 계속 호출하더라도, 리소스를 변경시키지 않는다.

-> GET, HEAD 

 

2. 멱등(Idempotent)

 

f(f(x)) = f(x)

즉, 메소드를 몇 번을 호출하던 결과가 항상 똑같다.

멱등 메소드에는 GET, PUT, DELETE 가 있으며, POST는 멱등이 아니다. 

회원 주문을 하는 프로세스를 수행한다고 하면, 두 번 호출하면 결제가 중복해서 발생한다. 

 

• 멱등의 활용 : 자동 복구 메커니즘
• 서버가 정상적인 응답을 주지 못했을 때

 

3. 캐싱(Cacheable)

 

캐싱은 이미 가져온 데이터나 계산된 결과값의 복사본을 저장함으로써 처리 속도를 향상시키고, 이 과정을 통해 이후 요청을 더 빠르게 처리한다. 대부분의 프로그램이 동일한 데이터나 명령어에 반복하기 때문에 캐싱은 효율적인 아키텍처 패턴이다. 

 

브라우저는 한번 요청한 파일은 그 이후에 요청이 다시 들어오면, 캐싱을 사용한다. 

만약 캐싱된 내용이 변경되는 것을 어떻게 브라우저는 감지할까 ?

 

현재 우리가 사용하는 방법은 HTTP Headers를 이용한다. 

HTTP Headers는 파일이 이전과 비교하여 변경 되었는가를 체크하는 validation고 캐시의 만료 여부를 체크하는 freshnewss로 구성된다.