HTTP 메서드의 안전, 멱등, 캐시가능 개념 이해하기

HTTP 메서드(GET/POST...)와 안전, 멱등, 캐시가능 개념

 

HTTP API란

HTTP API는 HTTP 프로토콜을 사용하여 인터넷을 통해 통신하는 방법입니다. 일반적으로는 클라이언트에서 서버측으로 요청을 보낸후에 응답을 다시 받을수있는 엔드포인트의 집합으로 구성됩니다.

웹 애플리케이션 및 기타 네트워크 소프트웨어 시스템을 구축하는 데 널리 사용되고 서로 다른 소프트웨어 구성 요소가 표준화된 방식으로 데이터를 통신하고 교환할 수 있습니다.

 

HTTP API의 장점

• HTTP API는 HTTP를 지원하는 모든 프로그래밍 언어 또는 플랫폼과 함께 사용할 수 있으므로 플랫폼 독립적이다.
• HTTP 및 웹 프로그래밍에 대한 기본 지식만 있으면 되므로 상대적으로 구현하기 쉽다.
• 증가된 트래픽을 처리하기 위해 더 많은 서버를 추가하여 HTTP API를 수평으로 쉽게 확장할 수 있다.
• OAuth 및 SSL/TLS와 같은 다양한 인증 및 암호화 방법을 사용하여 보안을 유지할 수 있다.
• 캐싱 및 기타 성능 최적화 기술을 사용하여 응답 시간을 개선하고 서버 부하를 줄이도록 설계할 수 있다.
• 웹 브라우저, 모바일 앱 및 기타 웹 서비스를 비롯한 다양한 유형의 클라이언트를 지원하도록 설계할 수 있다.

 

요약하면 HTTP API는 플랫폼 독립성, 구현 용이성, 확장성, 보안, 향상된 성능 및 유연성을 비롯한 여러 이점을 제공합니다. 이러한 장점 덕분에 HTTP API는 웹 애플리케이션 및 기타 네트워크 시스템 구축에 널리 사용됩니다.

 

HTTP API 만들어보기

이전 포스팅에서 학습한 내용을 토대로 HTTP API의 각 기능마다 별도의 URL이 필요한것을 알수 있습니다. 회원관리를 위한 HTTP API를 개발할때 다음과 같이 URL 설계를 한다면 어떨까요?

기능	URL
회원 목록 조회	/read-member-list
회원 단일 조회	/read-member-by-id
회원 등록	/create-member
회원 수정	/update-member
회원 삭제	/delete-member

 

기능이 하는 역할과 비교해보면 그럴듯하게 작성한것 같지만 올바른 설계는 아닙니다. HTTP API를 설계할때 중점이 되야하는 부분은 리소스입니다. 위 예제에서 리소스는 회원이고 조회하거나 등록, 수정, 삭제 행위는 리소스에 대한 부가 기능입니다.

따라서 우리는 다음과같이 설계를 해야합니다.

기능	URL
회원 목록 조회	/members
회원 단일 조회	/members/{id}
회원 등록	/members/{id}
회원 수정	/members/{id}
회원 삭제	/members/{id}

그런데 회원 목록 조회는 그렇다쳐도 나머지 기능들의 URL이 모두 동일한데 클라이언트에서 어떻게 구분하여 서버에 데이터를 요청할수 있을까요??

 

HTTP 메서드 종류

HTTP 메서드의 종류는 GET, POST, PUT, DELETE, PATCH 등이 있고 각 메서드는 주로 사용되는 용도가 있습니다.

• GET: 서버에서 리소스를 조회
• POST: 서버에 처리할 데이터를 전송 (범용적인 메서드)
• PUT: 서버의 기존 리소스를 대체
• DELETE: 서버에서 리소스를 삭제
• PATCH: 서버에 있는 기존 리소스의 일부를 업데이트

 

1. GET

• GET 메서드는 리소스를 조회할때 주로 사용합니다.

• 서버로 검색조건을 전달할때는 query(쿼리 스트링)를 사용합니다.

  • 쿼리스트링: URL뒤에 key=value 형식으로 파라미터를 전달하는 방법, 물음표 (?) 기호로 시작하며 key,value 가 여러개일때는 (&) 기호로 구분합니다.
  • ex) http://my-site.co.kr?name=ksr930&age=30

 

2. POST

• 서버로 처리할 데이터를 전송할때 주로 사용합니다.
• 데이터를 새로 입력하거나 업데이트 하는 용도로 사용되는데 PUT, PATCH, POST 세가지중 어떤것을 사용할지 애매할때는 일반적으로 POST를 사용합니다.
• 리소스 조회시 보통 GET을 사용하지만 검색조건을 json형태로 전송해야 할때는 POST를 사용합니다.
• 명확하게 GET이나 DELETE 메서드를 구분할때를 제외하고 애매하다 싶으면 대부분 POST입니다.

 

3. PUT

• PUT은 기존 리소스를 무시하고 새로 덮어씌우는 메서드 입니다.
• POST와 다른점으로 리소스 생성이 아닌 특정 리소스를 수정하기 위한 용도로 URL을 지정합니다.
• 예) 회원 리소스 'ksr930' 사용자가 다음과 같은 회원정보를 가지고있을때 PUT을 사용하는 경우

-- 기존 정보
{
    "name": "ksr930",
    "age": 30,
    "address": "seoul"
}

-- PUT 메서드 전송
PUT/member/1010111 HTTP/1.1
Content-type: application/json
{
    "age":31
}

-- 변경된 정보
{
    "age":31
}

• 회원 정보에서 "age" 필드를 제외한 모든 정보가 사라지는 극단적인 상황을 예시로 들었는데 실무에서는 당연히 이런일이 없도록 설계를 잘 해야 합니다.

 

4. PATCH

• PATCH는 기존 리소스에서 변경된 데이터만 업데이트 하는 메서드입니다.
• PUT처럼 특정 리소스만 수정하기위해 URL을 알고있지만 전부 덮어씌우는게 아니라 변경된 데이터만 업데이트합니다.
• 예) 회원 리소스 'ksr930' 사용자가 다음과 같은 회원정보를 가지고있을때 PUT을 사용하는 경우

-- 기존 정보
{
    "name": "ksr930",
    "age": 30,
    "address": "seoul"
}

-- PUT 메서드 전송
PUT/member/1010111 HTTP/1.1
Content-type: application/json
{
    "age":31
}

-- 변경된 정보
{
    "name": "ksr930",
    "age": 31,
    "address": "seoul"
}

 

5. DELETE

• DELETE는 리소스를 삭제하는 메서드입니다.

 

HTTP 메서드의 속성들

HTTP 메서드의 속성에는 안전(Safe), 멱등(Idemptent Methods), 캐시가능(Cacheable Methods)이 있습니다.

 

1. 안전(Safe)

• 안전의 의미는 URL을 호출하여도 리소스가 변하지 않는것을 뜻합니다.
• GET/HEAD/OPTIONS/TRACE 메서드가 해당합니다.
• URL을 과도하게 호출하여 서버의 장애발생은 고려대상이 아니고 리소스의 변형유무만 봅니다.

 

2. 멱등(Idemptent Methods)

• 멱등은 수학용어의 의미로 연산을 여러번 적용하더라도 결과값이 항상 동일한것을 뜻합니다.
• GET/HEAD/PUT/DELETE/OPTIONS/TRACE 메서드가 해당됩니다.
• 특정 리소스를 GET 메서드로 계속 조회할때 다른 사용자가 PUT/DELETE 메서드로 리소스에 변형을 주면 GET의 결과가 달라지므로 멱등이 성립되지 않는다고 생각할수 있는데 멱등은 외부 요인으로 리소스가 변형되는것까지 고려하지 않습니다.

 

3. 캐시가능(Cacheable)

• 메서드 응답결과 리소스를 캐시로 사용할수 있는지에 대한 판단입니다.
• GET/HEAD/POST/PATCH 메서드가 해당됩니다.
• 실제로는 GET, HEAD 정도만 사용되는데 POST/PATCH 의 경우 BODY안에 있는 데이터까지 고려해야 하기때문에 복잡성의 이유로 잘 사용되지 않습니다.