HTTP 메서드

HTTP API를 만들어 보자

회원 정보를 관리하는 HTTP API를 설계해 봅시다. 요구사항은 다음과 같습니다:

• 회원 목록 조회
• 회원 상세 조회
• 회원 등록
• 회원 수정
• 회원 삭제

처음에는 다음과 같이 URI를 설계할 수 있습니다:

• 회원 목록 조회: /readMemberList
• 회원 상세 조회: /readMemberById
• 회원 등록: /createMember
• 회원 수정: /updateMember
• 회원 삭제: /deleteMember

이러한 URI 설계는 행동(액션)이 포함되어 있으며, 이는 좋은 설계가 아닙니다.

리소스를 중심으로 한 URI 설계

URI는 리소스를 식별하는 데 사용되어야 합니다.

리소스는 “회원”과 같은 개념이며, 행동(조회, 등록 등)은 리소스가 아닙니다.

잘못된 예시:

• 행동을 포함한 URI: /createMember, /deleteMember

올바른 설계:

• 리소스를 표현하는 URI: /members, /members/{id}

이렇게 리소스를 나타내는 URI로 설계하고, 행동은 HTTP 메서드로 표현합니다.

리소스와 행위의 분리

• 리소스: URI로 식별되는 대상(예: 회원).
• 행위: 리소스에 대한 동작(조회, 생성, 수정, 삭제 등).

행위는 HTTP 메서드를 통해 표현되며, URI에는 포함되지 않습니다.

예시:

• 회원 목록 조회: GET /members
• 회원 상세 조회: GET /members/{id}
• 회원 등록: POST /members
• 회원 수정: PUT /members/{id}
• 회원 삭제: DELETE /members/{id}

확인 문제

1. URI를 설계할 때 가장 중요한 것은 무엇인가요?
   답변: 리소스를 식별하는 것입니다. URI는 리소스를 나타내야 하며, 행위를 포함해서는 안 됩니다.
2. 행동(행위)은 HTTP API에서 어떻게 표현하나요?
   답변: HTTP 메서드를 통해 표현합니다. 예를 들어, GET, POST, PUT, DELETE 등이 있습니다.
3. 다음 중 올바른 URI 설계는 무엇인가요?
   a) /getMemberList
   b) /members

---

HTTP 메서드 - GET과 POST

HTTP 메서드는 클라이언트가 서버에 요청할 때 기대하는 행동을 나타냅니다.

가장 많이 사용하는 메서드는 GET과 POST입니다.

GET 메서드

• 목적: 리소스 조회.
• 특징:
  • 서버에서 리소스를 가져옵니다.
  • 요청 메시지에 바디를 포함하지 않습니다.
  • 요청 파라미터는 주로 URL의 쿼리 스트링을 통해 전달합니다.
• 예시:
  • 회원 목록 조회: GET /members
  • 특정 회원 조회: GET /members/{id}
  • 검색: GET /search?query=keyword

주의 사항

• GET 요청에 메시지 바디를 포함할 수 있으나,
  실무에서는 지원하지 않는 경우가 많아 사용하지 않습니다.
• 캐시 가능하며, 안전하고 멱등합니다.

POST 메서드

• 목적: 서버로 데이터를 전송하여 리소스를 생성하거나 프로세스를 처리.
• 특징:
  • 요청 메시지의 바디에 데이터를 포함하여 서버로 전송합니다.
  • 서버는 전달된 데이터를 기반으로 리소스를 생성하거나 프로세스를 수행합니다.
• 예시:
  • 회원 등록: POST /members
    • 요청 바디에 회원 정보를 포함.
  • 데이터 처리 요청: POST /process
    • 예를 들어, 주문 처리, 결제 처리 등.

POST의 활용

• 새로운 리소스 생성.
• 서버에서 데이터 처리 프로세스 실행.
• 주의: POST는 멱등하지 않으며, 동일한 요청을 여러 번 보내면 중복 생성 등의 문제가 발생할 수 있습니다.

GET과 POST 비교

특징	GET	POST
목적	리소스 조회	리소스 생성 또는 데이터 처리
요청 바디	사용하지 않음 (쿼리 스트링 사용)	사용함 (데이터를 바디에 포함)
멱등성	멱등함	멱등하지 않음
캐시 가능성	캐시 가능	캐시 불가능

확인 문제

1. GET 메서드는 언제 사용하나요?
   답변: 서버에서 리소스를 조회할 때 사용합니다.
2. POST 메서드의 주요 목적은 무엇인가요?
   답변: 서버로 데이터를 전송하여 새로운 리소스를 생성하거나 프로세스를 처리하는 것입니다.
3. GET 요청에서 데이터를 서버로 전송하려면 어떻게 해야 하나요?
   답변: URL의 쿼리 스트링을 사용하여 데이터를 전송합니다.
4. POST 요청은 멱등한가요?
   답변: 아닙니다. POST 요청은 멱등하지 않으며,
   동일한 요청을 여러 번 보내면 중복 생성 등의 문제가 발생할 수 있습니다.

---

HTTP 메서드 - PUT, PATCH, DELETE

PUT 메서드

• 목적: 리소스를 대체.
• 특징:
  • 요청한 리소스의 전체를 교체합니다.
  • 리소스가 존재하지 않으면 새로 생성합니다.
  • 클라이언트가 리소스의 위치(URI)를 알고 있어야 합니다.
• 예시:
  • 회원 정보 전체 수정: PUT /members/{id}
    • 요청 바디에 전체 회원 정보를 포함.

주의 사항

• 일부 필드만 포함하여 PUT 요청을 보내면, 해당 리소스는 요청 바디에 포함되지 않은 필드가 삭제됩니다.
• 기존 리소스를 완전히 대체하기 때문에 주의해야 합니다.

PATCH 메서드

• 목적: 리소스의 부분 변경.
• 특징:
  • 리소스의 일부 필드만 수정할 때 사용합니다.
  • 요청 바디에 변경할 필드만 포함합니다.
• 예시:
  • 회원 나이만 수정: PATCH /members/{id}
    • 요청 바디에 { "age": 30 } 포함.

DELETE 메서드

• 목적: 리소스 삭제.
• 특징:
  • 지정한 리소스를 삭제합니다.
• 예시:
  • 회원 삭제: DELETE /members/{id}

PUT과 PATCH 비교

특징	PUT	PATCH
목적	리소스 전체 대체	리소스 부분 수정
요청 바디	전체 리소스 데이터 포함	변경할 필드만 포함
리소스 존재 여부	없으면 생성, 있으면 대체	존재하는 리소스만 수정

확인 문제

1. PUT 메서드를 사용하여 일부 필드만 포함한 요청을 보내면 어떻게 되나요?
   답변: 리소스의 기존 필드 중 요청에 포함되지 않은 필드는 삭제됩니다.
   리소스가 요청 바디로 완전히 대체되기 때문입니다.
2. 리소스의 일부만 수정하려면 어떤 메서드를 사용해야 하나요?
   답변: PATCH 메서드를 사용합니다.
3. DELETE 메서드의 주요 목적은 무엇인가요?
   답변: 지정한 리소스를 삭제하는 것입니다.
4. PUT과 POST의 주요 차이점은 무엇인가요?
   답변: PUT은 클라이언트가 지정한 URI에 리소스를 대체하거나 생성하며, 멱등합니다.
   POST는 서버가 리소스의 위치를 결정하며, 멱등하지 않습니다.

---

HTTP 메서드의 속성

HTTP 메서드에는 몇 가지 중요한 속성이 있습니다:

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

이러한 속성은 HTTP 메서드의 특성과 사용 방법을 이해하는 데 중요합니다.

안전(Safe)

• 정의: 메서드를 호출해도 서버의 리소스가 변경되지 않음.
• 안전한 메서드: GET, HEAD
• 예시:
  • GET /members를 여러 번 호출해도 서버의 데이터는 변경되지 않습니다.

주의 사항

• 서버의 로그 증가나 통계 수치 변경 등은 안전 속성에서 고려하지 않습니다.
• 리소스 자체의 변경 여부만 고려합니다.

멱등(Idempotent)

• 정의: 동일한 요청을 한 번 또는 여러 번 연속적으로 수행해도 결과가 동일함.
• 멱등한 메서드: GET, PUT, DELETE, HEAD
• 멱등하지 않은 메서드: POST
• 예시:
  • DELETE /members/1을 여러 번 호출해도 결과는 동일하게 회원이 삭제된 상태입니다.
  • PUT /members/1으로 동일한 데이터를 여러 번 업데이트해도 결과는 동일합니다.

왜 멱등성이 중요한가?

• 자동 복구 메커니즘:
  • 네트워크 오류 등으로 요청이 실패했을 때, 클라이언트는 동일한 요청을 다시 시도할 수 있습니다.
  • 멱등한 메서드는 재시도해도 부작용이 없으므로 안전하게 재요청할 수 있습니다.

주의 사항

• 중간에 다른 요인으로 리소스가 변경되는 것은 멱등성에서 제외합니다.
• 동일한 클라이언트가 동일한 요청을 여러 번 했을 때의 결과를 고려합니다.

캐시 가능(Cacheable)

• 정의: 응답 결과를 캐시에 저장하여 재사용할 수 있음.
• 캐시 가능한 메서드: GET, HEAD (실무에서는 주로 이 두 가지)
• 예시:
  • 웹 브라우저는 GET 요청의 응답을 캐시에 저장하여, 동일한 요청 시 서버에 재요청하지 않고 캐시에서 데이터를 가져옵니다.

주의 사항

• POST나 PATCH는 스펙상 캐시 가능하지만, 실제로는 캐시로 사용되지 않습니다.
• 캐시 키 생성과 일관성 유지가 어려워서 실무에서는 GET만 캐시로 사용합니다.

확인 문제

1. 안전한 메서드란 무엇인가요?
   답변: 호출해도 서버의 리소스를 변경하지 않는 메서드입니다. 예를 들어, GET과 HEAD가 있습니다.
2. 멱등하지 않은 메서드는 어떤 것이 있으며, 그 이유는 무엇인가요?
   답변: POST 메서드는 멱등하지 않습니다.
   동일한 POST 요청을 여러 번 보내면 중복 생성 등의 부작용이 발생할 수 있기 때문입니다.
3. 왜 멱등성이 중요한가요?
   답변: 네트워크 오류 등으로 요청이 실패했을 때,
   클라이언트가 동일한 요청을 재시도해도 부작용이 없도록 하기 위해 중요합니다.
4. 실무에서 캐시로 사용되는 메서드는 무엇인가요?
   답변: GET과 HEAD 메서드입니다.