하루_한개_코딩

캐시(cache)란 ?

캐시는 컴퓨터 시스템의 성능을 향상시키고 데이터 접근 속도를 개선하기 위해 사용되는 중간 저장소입니다. 캐시는 이전에 접근한 데이터나 결과를 임시로 저장하여 동일한 데이터에 대한 다시 접근 시 원본 데이터를 다시 가져오지 않고 캐시에서 빠르게 반환함으로써 시스템 성능을 향상시킵니다.

캐시의 기본 동작은 다음과 같습니다:

1. 요청된 데이터 접근 : 클라이언트나 애플리케이션에서 어떤 데이터를 요청합니다.
2. 캐시 검사 : 요청된 데이터가 캐시에 이미 저장되어 있는지 확인합니다.
3. 캐시에 데이터가 있을 경우: 요청된 데이터가 캐시에 저장되어 있으면, 원본 데이터를 다시 가져오지 않고 캐시에서 데이터를 반환합니다. 이로 인해 데이터 접근 속도가 빨라집니다.
4. 캐시에 데이터가 없을 경우: 요청된 데이터가 캐시에 저장되어 있지 않으면, 원본 데이터를 가져와서 캐시에 저장한 후에 클라이언트에 반환합니다. 이후 동일한 데이터에 대한 요청이 들어오면 캐시에서 데이터를 반환하게 됩니다.
   
   

요청 메세지를 보낼 때, cache-control : max-age=60으로 60초의 시간동안은 요청 받았던 파일이나 이미지 등을 브라우저 캐시에 보관합니다. 이 후, 같은 파일의 요청메세지가 GET메서드로 오면, 캐시에 저장해두었던 응답결과로 반환합니다. 캐시 유효 시간이 초과했는데, 동일한 데이터를 요청한다면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신합니다. 이 때, 다시 네트워크 다운로드가 발생하는 비효율 적인 상황이 발생합니다.

📋 검증 헤더와 조건부 요청

해당 사항을 해결할 수 있는 방법이 검증 헤더 , 조건부 요청 입니다. 

검증 헤더와 조건부 요청은 HTTP 요청과 응답에 사용되는 기능으로, 웹 서버와 클라이언트 간의 효율적인 통신을 도와줍니다. 이를 통해 불필요한 데이터 전송을 줄이고 네트워크 부하를 감소시킬 수 있습니다.

1. 검증 헤더(Validation Headers) : 검증 헤더는 서버가 리소스(예: 웹 페이지, 이미지, 동영상 등)의 변경 여부를 클라이언트에게 알려주는 역할을 합니다. 클라이언트는 이 헤더를 통해 리소스를 캐시하고, 이후 동일한 리소스에 대한 요청 시 서버로부터 리소스의 변경 여부를 확인합니다.동작 원리는 다음과 같습니다
   
   주요 검증 헤더
   👉 Last-Modified : HTTP 응답 헤더 중 하나로, 웹 서버가 특정 리소스의 최종 수정 시간을 클라이언트에게 알려주는 역할을 합니다. 이 헤더는 클라이언트가 해당 리소스를 다시 요청할 때, 서버가 리소스의 변경 여부를 확인하는 데 사용됩니다.
   
   
   1. 웹 서버는 특정 리소스에 대한 요청이 들어올 때, 해당 리소스의 최종 수정 시간을 계산합니다.
   2. Last-Modified 헤더에 이 최종 수정 시간을 포맷에 맞추어 기록하여 HTTP 응답으로 클라이언트에게 전달합니다.
   3. 클라이언트는 해당 리소스를 다시 요청할 때, If-Modified-Since 헤더를 함께 보내서 서버에게 해당 리소스의 변경 여부를 질의합니다.
   4. 서버는 If-Modified-Since 헤더에 포함된 시간과 리소스의 최종 수정 시간을 비교하여 리소스의 변경 여부를 판단합니다.
      
      • If-Modified-Since의 시간보다 최종 수정 시간이 이후라면, 리소스가 변경되었다는 의미로 200 OK 응답과 함께 실제 데이터를 보냅니다.
      • If-Modified-Since의 시간과 최종 수정 시간이 동일하거나 이전이라면, 리소스가 변경되지 않았다는 의미로 304 Not Modified 응답 헤더만을 반환하고, 실제 데이터 Body에 포함하지 않습니다.
        
        
   네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드가 되며, 클라이언트는 캐시에 저장되어 있는 데이터를 재활용 할 수 있습니다. 브라우저에서 파일 1개를 클릭한 후 , 해당 브라우저에서 아무런 실행 없이 새로고침을 해보면 status가 304임을 확인할 수 있습니다.
   
   

304로 응답이 왔다는 것은 요청 메세지 Request 시 if-modified-since 을 작성해서 보낸 것을 의미합니다. 해당 시간이 적힌 이후로의 데이터변경이 없음을 의미하므로 요청한 데이터와 동일한 데이터가 쿠키에 있기 때문에 새로이 응답 메세지를 보낸 것이 아니라 캐시에 보관되어 있던 응답 메세지를 보낸 것입니다.

👉 ETag (Entity Tag) : 리소스의 고유한 식별자를 나타내는 문자열로, 리소스가 변경되면 변경된 ETag 값을 반환합니다. 이 식별자는 해당 리소스의 내용이 변경되었는지를 클라이언트가 확인하는 데 사용됩니다.

동작 원리는 다음과 같습니다:

1. 웹 서버는 특정 리소스의 데이터를 해시 함수 등을 사용하여 유일한 식별자를 생성합니다.
2. ETag 헤더에 이 식별자를 포맷에 맞추어 기록하여 HTTP 응답으로 클라이언트에게 전달합니다.
3. 클라이언트는 해당 리소스를 다시 요청할 때, If-None-Match 헤더를 함께 보내서 서버에게 해당 리소스의 변경 여부를 질의합니다.
4. 서버는 If-None-Match 헤더에 포함된 식별자와 현재 리소스의 식별자를 비교하여 리소스의 변경 여부를 판단합니다.
   • If-None-Match의 식별자와 현재 리소스의 식별자가 일치하지 않으면, 리소스가 변경되었다는 의미로 200 OK 응답과 함께 실제 데이터를 보냅니다.
   • If-None-Match의 식별자와 현재 리소스의 식별자가 동일하면, 리소스가 변경되지 않았다는 의미로 304 Not Modified 응답을 반환하고, 실제 데이터를 포함하지 않습니다.

캐시는 주로 웹 브라우저, 웹 서버, 프록시 서버 등에서 사용되며, 웹 페이지의 이미지, 스타일 시트, 스크립트 파일 등을 캐시하여 사용자에게 빠른 웹 페이지 로딩 속도를 제공하는 데 활용됩니다. 또한, 데이터베이스 쿼리 결과나 API 응답 결과 등을 캐시하여 데이터 접근 속도를 개선하는 데에도 활용됩니다.

캐시 제어 (cache-control)이란?

캐시 제어 헤더는 HTTP 응답과 요청에 포함되어 캐시 동작을 제어하는데 사용되는 헤더들을 말합니다. 이러한 헤더들을 이용하여 클라이언트와 서버 간의 캐시 동작을 조정하고, 캐시의 적용 범위와 지속 시간 등을 설정할 수 있습니다.

1. Cache-Control: 캐시 동작을 설정합니다. 주요 지시자로는 public, private, no-cache, max-age, s-maxage 등이 있습니다.
   Cache-control : max-age → 캐시가 어느 기간동안 유효한지를 입력합니다. 단위는 초 단위 입니다.
   Cache-control : no-cache → 캐시를 사용하지 않도록 지시하는 지시자 입니다. HTTP 응답의 Cache-Control 헤더에서 사용되며, 이 지시자가 포함된 경우 클라이언트와 중개 서버는 응답을 캐시하지 않고 매번 원본 서버에 검증하여 새로운 응답을 가져옵니다.
   Cache-control : no-store → 캐시를 완전히 비활성화하는 캐시 제어 지시자 no-store 지시자가 포함된 응답은 민감한 정보나 개인 정보와 같이 보안상 민감한 데이터를 포함하는 경우 사용됩니다. 따라서 no-store 지시자는 이러한 상황에서 캐시를 사용하지 않도록 지시하여 보안을 강화합니다.
   Cache-control : must-revalidate → 캐시된 데이터가 유효한지 원본 서버와 검증을 수행해야 합니다. 원 서버 접근 실패 시 반드시 오류가 발생해야 합니다. (504-Gateway Timeout) 캐시된 데이터를 사용하기 전에 원본 서버와 검증을 거쳐야 하며, 만료된 후 최초 조회 시 반드시 원본 서버에 검증 후 새로운 데이터를 가져와서 사용합니다.
2. Pragma: 캐시 동작을 설정하는데 사용되지만, 일반적으로 사용되지 않으며 Cache-Control 헤더를 대신 사용합니다.
3. Expires (하위 호환) : 캐시 만료 시간을 설정합니다. 정확한 날짜로 지정해야 하고, max-age와 expires가 같이 쓰이면 expires는 무시됩니다. 응답이 해당 시간 이후에는 더 이상 캐시를 사용하지 않고 서버에 재요청합니다. 하지만 이 헤더는 오래된 방식이므로 Cache-Control의 max-age를 더 권장합니다.

프록시 캐시란?

프록시 캐시는 클라이언트와 서버 사이에 위치하여 클라이언트의 요청을 대신 받아서 서버로 전달하고, 서버의 응답을 클라이언트에게 전달하는 역할을 하는 중개 서버입니다. 이러한 프록시 서버는 원격 서버와 클라이언트 간의 통신을 중개하며, 캐시를 사용하여 네트워크 트래픽을 줄이고 응답 속도를 향상시킵니다.

프록시 캐시는 서버로부터 받은 응답을 캐시에 저장하여 동일한 요청이 들어올 경우 새로운 요청을 서버로 전달하지 않고 캐시된 응답을 클라이언트에게 바로 제공합니다. 이렇게 함으로써 원격 서버에 불필요한 요청을 줄이고, 클라이언트의 요청에 더 빠르게 응답할 수 있습니다.

이렇게 함으로써, 동일한 요청이 반복되거나 여러 클라이언트가 동일한 리소스를 요청할 경우, 프록시 서버는 원격 서버에 대한 중복 요청을 줄여 네트워크 트래픽을 최소화하고 응답 속도를 향상시킵니다. 또한 프록시 캐시는 웹 서버의 부하를 감소시키고 클라이언트에게 빠른 응답을 제공하여 사용자 경험을 향상시킵니다.

여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자료를 가져올 수 있습니다. 이는 같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있기 때문입니다. 이 때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시 서버의 캐시를 public 캐시라 합니다.

💥 캐시 무효화

캐시 무효화(Cache Invalidation)란, 캐시에 저장된 데이터가 유효하지 않아서 더 이상 사용해서는 안 된다는 표시를 내리는 과정을 말합니다. 캐시는 원본 서버의 데이터를 저장하여 클라이언트에게 빠르게 응답을 제공하는데 사용되지만, 원본 데이터가 변경되거나 삭제되었을 때 캐시에 저장된 데이터가 더 이상 유효하지 않게 될 수 있습니다. 이때 캐시 무효화를 통해 클라이언트가 더 이상 캐시된 데이터를 사용하지 않도록 하고, 새로운 데이터를 다시 원본 서버에서 가져와서 캐시를 업데이트하는 작업이 필요합니다.

✍️ HTTP 헤더의 일반 정보

• Referer는 HTTP 요청 헤더의 하나로, 웹 브라우저가 현재 요청을 보내는 페이지의 이전 페이지(리퍼러)의 URL을 나타냅니다. 현재 요청된 페이지의 이전 웹페이지 주소를 의미합니다.
  이 헤더는 웹 서버에게 클라이언트가 어떤 페이지에서 링크를 클릭하거나 리소스를 요청하는지를 알려주는 역할을 합니다. ex) 구글에서 검색 후, 1개의 게시글을 클릭한 후 http 메서드를 확인하게 되면 Referer에 이전 페이지 URL이 뜨는 것을 확인할 수 있습니다

이렇게 Referer 정보를 서버에 전달함으로써 웹 서버는 사용자의 행동에 대한 정보를 얻을 수 있고, 특정 페이지로부터의 유입 경로나 링크 클릭 등을 추적할 수 있습니다. Referer 헤더는 일부 보안 및 개인 정보 보호 문제를 야기할 수 있으며, 때로는 보안 상의 이유로 사용하지 않을 수도 있습니다. 웹 개발자가 웹 사이트의 보안을 강화하거나 사용자의 개인 정보를 보호해야 할 때는 Referer 헤더를 사용하지 않도록 설정할 수 있습니다. 이렇게 하면 Referer 헤더가 요청에 포함되지 않거나 빈 값을 가지게 됩니다.

• User-Agent는 유저 에이전트 애플리케이션 정보로 HTTP 요청 헤더 중 하나로, 웹 브라우저나 클라이언트 애플리케이션이 서버에게 자신의 소프트웨어와 버전, 운영체제 등의 정보를 전달하는 역할을 합니다. 이 정보를 통해 서버는 요청을 보낸 클라이언트의 특성과 기능을 파악하여 적절한 응답을 제공할 수 있습니다.

    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/94.0.4606.61 Safari/537.36

위 예시에서 "Mozilla/5.0"은 클라이언트가 Mozilla 기반의 웹 브라우저를 사용한다는 것을 나타내며, "Windows NT 10.0; Win64; x64"는 사용자의 운영체제 정보입니다. "AppleWebKit/537.36"은 웹 킷 엔진의 버전을 의미하고, "Chrome/94.0.4606.61"은 브라우저의 버전을 나타냅니다. "Safari/537.36"은 브라우저가 Safari 엔진도 사용한다는 것을 의미합니다.

User-Agent 정보를 이용하여 서버는 클라이언트의 특성에 맞는 콘텐츠를 제공하거나, 웹 사이트의 호환성을 유지하기 위해 필요한 처리를 할 수 있습니다. 또한 이 정보를 이용하여 사용자의 기기나 브라우저 등을 파악하여 통계를 수집하거나 분석하는 용도로도 활용될 수 있습니다. 하지만 사용자의 개인정보 보호를 위해 브라우저는 사용자 에이전트 문자열을 사용자가 컨트롤할 수 있도록 하여 원치 않는 추적을 방지할 수 있게끔 설계되어 있습니다.

• Host : 요청하는 호스트(도메인)의 이름을 나타냅니다. 하나의 웹 서버가 여러 도메인에 대해 서비스하는 경우 유용하게 사용됩니다. HOST 헤더는 요청에서 사용되는 필수적입니다. 하나의 서버에서 여러 개의 웹 사이트를 호스팅하는 경우, Host 헤더를 사용하여 클라이언트가 어떤 도메인으로 요청을 보내는지를 구분할 수 있습니다. 서버는 이를 통해 요청을 받은 후 해당 도메인에 맞는 웹 사이트의 콘텐츠를 반환할 수 있습니다.
  
  
• Location : HTTP 응답 헤더 중 하나로, 클라이언트가 요청한 리소스가 다른 위치에 있을 경우 리다이렉션(다른 곳으로 이동)을 알려주는데 사용됩니다. 즉, 서버가 클라이언트에게 요청한 리소스의 위치를 새로운 URL로 바꿔서 제공할 때 Location 헤더를 사용합니다.예를 들어, 클라이언트가 *http://example.com/old-page를 요청했지만 이 페이지가 http://example.com/new-page로 이동되었다면, 서버는 다음과 같은 응답을 반환할 수 있습니다.
  
  
• 보통 Location 헤더는 HTTP 상태 코드 3xx (리다이렉션)와 함께 사용되며, 클라이언트는 이 헤더를 확인하여 새로운 URL로 다시 요청을 보내게 됩니다. 리다이렉션은 클라이언트가 원래 요청한 리소스의 위치가 변경되었거나, 보안 등의 이유로 다른 URL로 이동해야 할 때 사용됩니다.

Header filed 작성 문법
📋 field-name(아래에서는 Host) ” : “ OWS field-value OWS (ows : 띄어쓰기 허용)

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담고있습니다.
ex) 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등

대표적인 용도는 아래와 같습니다.

1. 컨텐츠 관련 헤더: 컨텐츠 유형(Content-Type), 컨텐츠 길이(Content-Length) 등의 정보를 포함합니다.
   
   
2. 캐시 관련 헤더: 캐시의 동작을 제어하는 헤더로, 캐시 지시자(Cache-Control), 만료 날짜(Expires) 등을 포함합니다.
   
   
3. 인증과 보안 관련 헤더: 사용자 인증과 보안에 관련된 정보를 담고 있으며, Authorization, Set-Cookie 등이 있습니다.
   
   
4. 요청과 응답 관련 헤더: 요청과 응답의 상태와 메타 정보를 포함합니다. 예를 들어, Accept-Language, User-Agent 등이 있습니다.
   
   
5. 리다이렉션 관련 헤더: 리다이렉션 정보를 제공하는 헤더로, Location, Refresh 등이 있습니다.
   
   
6. 요청 조건 관련 헤더: 서버에게 요청에 대한 조건을 지정하는 헤더로, If-Modified-Since, If-None-Match 등이 있습니다.
   
   
7. 프록시 관련 헤더: 프록시 서버 동작을 제어하는 헤더로, Via, Proxy-Authenticate 등이 있습니다.
   
   
   

메세지 본문 (message Body)을 통해 표현 데이터를 전달합니다. 표현은 요청이나 응답에서 전달할 실제 데이터이며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다. (데이터 유형(html, json), 데이터 길이, 압축 정보 등) / 표현 헤더는 전송, 응답 둘 다에서 사용이 가능합니다.

📋 HTTP 헤더의 종류 1. 표현 헤더 & 표현 데이터

표현 헤더(Representation Header)는 HTTP 응답 메시지의 헤더 부분에 포함되는 정보로, 서버가 클라이언트에게 제공하는 리소스(Representation)의 특성을 설명합니다. 표현 헤더는 리소스 자체의 특성이나 리소스와 관련된 메타데이터 등을 포함하며, 클라이언트는 이를 통해 리소스를 적절하게 해석하고 처리할 수 있습니다.

• Content-Type : 응답 본문(페이로드)의 미디어 타입을 지정합니다. 이 헤더는 서버가 클라이언트에게 전달하는 컨텐츠의 종류를 나타냅니다. 예를 들어, "Content-Type: application/json"은 응답 본문이 JSON 형식임을 나타냅니다.
  
  
• Content-Length : 응답 본문의 길이를 바이트 단위로 지정합니다. 이 헤더는 클라이언트가 응답 본문의 크기를 미리 알 수 있도록 합니다.
  
  
• Content-Encoding : 응답 본문의 압축 방식을 지정합니다. 클라이언트는 이 헤더를 통해 응답 본문이 압축되어 있다면 이를 해제하여 사용할 수 있습니다. 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제합니다. ex) gzip , deflate, identity
  
  
• Content-Language : 응답 본문의 언어를 지정합니다. 클라이언트는 이 헤더를 통해 응답 본문의 언어를 인식하여 적절히 표시할 수 있습니다. 표현 데이터의 자연언어를 표현합니다. ex) ko, en, en-US 국가별 공식 사이트에 접속하면 자기한테 맞는 언어로 변경 시에 확인할 수 있습니다.

표현 헤더는 클라이언트와 서버 간의 컨텐츠 교환에 중요한 역할을 수행하며, 클라이언트는 이러한 헤더를 이해하고 적절히 활용하여 리소스를 처리합니다.

📋 HTTP 헤더의 종류 2. 협상 헤더 (Content Negotitation)

협상 헤더(Content Negotiation) 는 클라이언트와 서버 간에 어떤 컨텐츠 타입(미디어 타입)을 사용할 것인지 협상하기 위해 사용되는 HTTP 헤더입니다. 클라이언트가 요청한 리소스에 대해 서버가 여러 형식의 컨텐츠를 가지고 있을 때, 클라이언트가 선호하는 컨텐츠 타입을 알려주고 서버는 해당 요청에 가장 적합한 컨텐츠 타입을 선택하여 응답합니다.

• Accept: 클라이언트가 선호하는 컨텐츠 타입을 지정합니다. 예를 들어, "Accept: application/json"은 클라이언트가 JSON 형식의 컨텐츠를 선호한다는 것을 의미합니다.
  
  
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩을 지정합니다.
  
  
• Accept-Language: 클라이언트가 선호하는 언어를 지정합니다. 서버는 이를 참고하여 적절한 언어로 된 컨텐츠를 선택하여 응답합니다. Quality Values 또는 Q-values는 HTTP 요청 및 응답 헤더에서 사용되는 매개변수로, 클라이언트가 선호하는 콘텐츠 유형 또는 언어를 표현하는 데 사용됩니다.
  Quality Value는 0과 1 사이의 실수 값으로 표현되며, 1에 가까울수록 클라이언트가 해당 미디어 타입을 더 선호한다는 것을 나타냅니다. 예를 들어, Accept: application/json;q=0.8, text/html;q=0.9 는 클라이언트가 JSON을 0.8의 우선 순위로, HTML을 0.9의 우선 순위(더 높은 우선순위)로 선호한다는 것을 나타냅니다.
  
  
• Accept-Encoding: 클라이언트가 선호하는 컨텐츠 압축 방식을 지정합니다. 서버가 지원하는 압축 방식 중에서 클라이언트가 선호하는 방식을 선택하여 압축된 컨텐츠를 제공할 수 있습니다.

협상 헤더를 사용하면 클라이언트는 자신이 원하는 컨텐츠 타입이나 언어 등을 명시하여 서버에 전달할 수 있습니다. 서버는 클라이언트의 요청을 기반으로 적절한 형식의 컨텐츠를 선택하여 응답하므로, 클라이언트와 서버 간의 상호작용이 더 유연해집니다. 이를 통해 다국어 지원, 다양한 미디어 타입 지원 등을 할 수 있습니다.

✍️ HTTP 전송 방식

1. 압축 전송(Compression Transfer) : 압축 전송은 HTTP 메시지를 클라이언트와 서버 간에 압축하여 전송하는 방식입니다. 이를 통해 데이터의 크기를 줄이고 전송 시간과 대역폭을 절약할 수 있습니다. 일반적으로 클라이언트가 요청 헤더에 “Content-Encoding"을 지정하여 어떤 압축 알고리즘을 지원하는지 서버에 알려주고, 서버는 해당 알고리즘 중에서 선택하여 압축하여 응답을 전송합니다. 대표적으로 gzip과 deflate 압축 알고리즘이 사용됩니다.
   
   
2. 분할 전송(Chunked Transfer) : 분할 전송은 큰 크기의 데이터를 여러 개의 작은 조각(Chunk)으로 나누어 전송하는 방식입니다. 이를 통해 데이터가 일부분만 도착해도 빠르게 전송되어 사용자 경험을 향상시킬 수 있습니다. 일반적으로 서버가 요청 헤더에 "Transfer-Encoding: chunked"를 포함하여 응답을 분할 전송한다고 알려주며, 클라이언트는 이를 확인하고 조각별로 데이터를 수신합니다.
   
   
3. 단순 전송(Simple Transfer) : 단순 전송은 HTTP 메시지를 그대로 전송하는 방식입니다. 압축이나 분할 없이 요청과 응답을 전체적으로 그대로 전송합니다. 일반적으로 압축이나 분할이 필요하지 않을 경우에 사용됩니다.
   
   
4. 범위 전송(Range Request) : HTTP 요청에서 클라이언트가 서버로부터 원하는 리소스의 특정 범위만을 요청하는 기능입니다. 클라이언트가 요청 헤더에 "Range"를 지정하여 원하는 범위를 표시하고, 서버는 해당 범위만을 응답으로 보내주는 방식으로 동작합니다.

HTTP 상태 코드는 클라이언트가 서버에 HTTP 요청을 보내고, 서버가 해당 요청을 처리한 결과를 클라이언트에게 반환할 때 사용되는 3자리 숫자로 이루어진 코드입니다. 각 상태 코드는 요청의 성공, 실패 또는 처리 상태를 나타내는 역할을 합니다.

1xx (Informational) : 요청이 받아들여지고 처리 중임을 나타냅니다. (거의 사용 X)
2xx (Success) : 요청이 성공적으로 처리되었음을 나타냅니다.
3xx (Redirection) : 요청을 완료하기 위해 추가 작업이 필요함을 나타냅니다.
4xx (Client Errors) : 클라이언트의 요청에 오류가 있음을 나타냅니다.
5xx (Server Errors) : 서버가 요청을 처리하는 동안 오류가 발생했음을 나타냅니다.

만약 모르는 상태 코드가 나타난다면 클라이언트는 상위 상태코드로 해석해서 처리해줍니다.
예를 들어 299 ??? → 2XX로 해석하여 (Successful)을 의미한다고 생각하면 됩니다.

1. 2xx (Success) : 성공 (클라이언트의 요청을 성공적으로 처리)
   200 OK: 요청이 성공적으로 처리되었음을 나타냅니다.
   201 Created : 요청에 의해 새로운 리소스가 생성되었음을 나타냅니다. 자원생성, Location 헤더 有 204 No Content: 요청은 성공적으로 처리되었지만, 응답으로 반환할 내용이 없음을 나타냅니다.
   204 No Content ex) 웹 브라우저에서 웹 문서 편집기를 사용할 때 저장을 하게 되면 데이터가 POST를 통해 서버로 전달되었지만 , 응답할 본문을 받을 필요는 없기 때문에 결과 내용은 없이 204 메세지만으로 성공인식이 가능
   
   
2. 3xx (Redirection) : 리다이렉션 (요청을 완료하기 위해 추가 조치를 요청)
   웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 , Location 위치로 자동 이동합니다.
   
   301 Moved Permanently : 요청한 리소스의 URI가 영구적으로 새로운 URI로 변경되었음을 나타냅니다. 클라이언트는 새로운 URI를 사용하여 요청을 다시 시도해야 합니다.
   302 Found: 요청한 리소스의 URI가 일시적으로 새로운 URI로 변경되었음을 나타냅니다. 클라이언트는 새로운 URI를 사용하여 요청을 다시 시도해야 합니다. (주로 리다이렉트에 사용)
   303 See Other : 서버가 클라이언트의 요청을 완료하였으며, 리소스가 다른 URI에 있을 때 사용됩니다. 주로 POST 요청의 결과를 리다이렉트할 때 사용됩니다.
   304 Not Modified : 클라이언트가 이전에 이미 요청한 리소스가 변경되지 않았음을 서버가 알고 있을 때 사용됩니다. 클라이언트가 캐시된 버전을 사용하여 리소스를 가져오도록 유도합니다. 이 때, 서버는 실제 리소스의 내용을 응답으로 보내지 않고, ‘ETag’ 또는 ‘Last-Modified’ 헤더 등을 사용하여 클라이언트의 캐시를 업데이트 할 수 있습니다.
   307 TemporaryRedirect : 클라이언트의 POST 요청은 리다이렉트된 URI로 재전송되지만, 메서드는 변경되지 않습니다. 즉, 클라이언트의 POST 요청은 리다이렉트된 URI에서도 POST로 처리됩니다.
   308 Permanent Redirect : 301 Moved Permanently와 비슷하지만, POST 요청에서의 처리 방식이 다릅니다.클라이언트의 POST 요청은 리다이렉트된 URI로 재전송되며, 메서드도 변경됩니다. 즉, 클라이언트의 POST 요청은 리다이렉트된 URI에서는 GET으로 처리됩니다.
   
   - 영구 리다이렉션(301, 308) : 특정 리소스의 URI가 영구적으로 이동 ex) /event → /new-event
   리소스의 URI가 영구적으로 이동한 경우, 원래의 URL을 사용하지 않아 검색 엔진 등에서도 변경을 인지합니다. 301 리다이렉트시 요청 메서드가 GET으로 변하고 , 본문이 제거될 수 있습니다. 308의 기능은 301과 동일하지만, 308은 요청 메서드와 본문을 똑같이 유치하고, 처음 POST로 보내면 리다이렉트도 동일합니다.
   
   - 일시 리다이렉션(302, 303, 307) : 웹 서버가 클라이언트의 요청을 일시적으로 다른 URI로 리다이렉트하는 것
   검색 엔진 등에서 URL을 변경하면 안됩니다. 302, 303, 307의 기능은 거의 동일하지만, 302는 본문이 제거될 수 있다는 점, 303은 요청메서드가 GET으로 변경되는 점, 307은 요청 메서드와 본문을 유지(요청 메서드를 변경하면 안됨)하는 차이점 등이 있습니다.
   
   PRG : Post / Redirect / Get
   ex ) POST로 주문 후에 웹 브라우저를 새로고침 하면 새로고침은 다시 요청되나 , 중복으로 주문 될 수 있습니다.  
   
   PRG는 Post-Redirect-Get의 약자로, 웹 애플리케이션에서 폼 데이터를 안전하게 제출하는 방법 중 하나입니다. 이러한 방식은 사용자 경험을 향상시키고 중복 폼 제출로 인한 문제를 방지하는 데 도움이 됩니다.
   
   Post (제출) : 사용자가 폼을 작성하고 제출합니다. 이 때, HTTP POST 메서드를 사용하여 데이터를 서버로 보냅니다.
   Redirect (리다이렉트) : 서버는 폼 데이터를 처리한 후, 적절한 결과 페이지로 리다이렉트(이동)합니다. 이때, HTTP 상태 코드 303 See Other 또는 307 Temporary Redirect를 사용하여 리다이렉트합니다.
   Get (얻기) : 리다이렉트된 결과 페이지를 사용자에게 보여줍니다. 이때, HTTP GET 메서드를 사용하여 페이지를 요청합니다.
   
   PRG 패턴을 사용하면 사용자가 새로 고침 또는 뒤로 가기를 눌렀을 때 중복 제출을 방지할 수 있습니다. 폼 데이터가 POST로 제출되기 때문에 브라우저에서 다시 로드할 경우 폼 데이터를 다시 제출하는 것을 방지합니다. 대신 리다이렉트를 통해 결과 페이지로 이동하여 사용자에게 정상적인 사용자 경험을 제공합니다.
   
   PRG 패턴은 웹 애플리케이션에서 폼 처리와 리다이렉트를 결합하여 사용자가 의도하지 않은 작업의 반복을 방지하고 사용성을 향상시키는 데에 널리 사용되는 패턴 중 하나입니다.

📋 기타 리다이렉션 304 Not Modified : 클라이언트가 이전에 이미 요청한 리소스가 변경되지 않았음을 서버가 알고 있을 때 사용합니다. 클라이언트에게 리소스가 수정되지 않았음을 알려주기 때문에 클라이언트는 로컬 PC에 저장된 캐시를 재사용 할 수 있습니다. 304 응답은 응답에 메세지 바디를 포함하면 안됩니다

특수 리다이렉션 : 결과 대신 캐시를 사용

3. 4xx (Client Error) : 클라이언트 오류 ( 오류의 원인이 클라이언트)
400대 오류는 클라이언트의 요청이 이미 잘못되어있기 때문에 똑같은 재시도가 계속 실패 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 상태입니다.

400 Bad Request : 클라이언트의 요청이 잘못되었거나 서버가 요청을 이해할 수 없는 경우를 나타냅니다. 요청 구문, 주고받는 메세지에서의 오류가 발생했을 때이고 클라이언트는 요청 내용을 다시 검토하고 보내야 합니다. (ex . 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 )

401 Unauthorized : 인증되지 않은 사용자가 보호된 리소스에 접근하려고 시도한 경우를 나타냅니다. 401 오류 발생 시 클라이언트는 응답에 WWW-Authenticate 헤더와 함께 인증 정보를 제공해야 합니다. 

Authentication(인증) : 본인이 누구인지 확인 ( 로그인 )
Authorization(인가) : 권한 부여 ( Admin 권한 처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)

403 Forbidden : 인증된 사용자라도 해당 리소스에 접근 권한이 없는 경우를 나타냅니다. 접근이 거부됩니다.

404 Not Found : 요청한 리소스를 찾을 수 없음을 나타냅니다. 요청한 URI가 서버에 존재하지 않거나 라우팅되지 않았을 때 발생합니다. 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을때 발생합니다.

4. 5xx (Server Error) : 서버 오류 (서버문제로 오류 발생)

500 Internal Server Error : 서버 내부에서 오류가 발생한 경우(대부분)를 나타냅니다. 서버에 오류가 발생하여 요청을 처리할 수 없는 상태입니다.

503 Service Unavailable : 서버가 현재 요청을 처리할 수 없는 상태이거나 유지보수 중인 경우를 나타냅니다. 잠시 후에 다시 시도하라는 의미를 갖습니다. 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리 할 수 없는 상황입니다.서버에 문제가 있기 때문에 재시도하면 성공할 수도 있습니다 (복구가 되는 상황)

HTTP 메서드의 속성은 다음과 같습니다.

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

1. 안전(Safe): 안전한 메서드는 서버의 상태를 변경하지 않고 읽기 작업만 수행하는 메서드입니다. GET 메서드가 단순한 조회만 하기 때문에 가장 일반적인 안전한 메서드입니다. 안전한 메서드는 동일한 요청을 여러 번 보내더라도 서버의 상태나 데이터를 변경하지 않으므로, 캐싱이나 프록시 서버에 의해 재사용될 수 있습니다.
   
   만약 계속 호출이 되어서 로그같은게 쌓인다면 장애가 발생할 수 있는데, 안전이라는 점은 해당 리소스의 상태변화에 대해서만 고려하기때문에 장애가 발생할 경우는 고려하지 않습니다.
   
   
2. 멱등(Idempotent): 멱등한 메서드는 같은 요청을 여러 번 보내더라도 항상 동일한 결과를 얻을 수 있는 메서드입니다. GET, HEAD, PUT, DELETE 메서드는 멱등한 메서드입니다. 예를 들어, 같은 DELETE 요청을 여러 번 보내도 리소스는 한 번만 삭제됩니다. 이러한 특성은 재시도 등에 유용하며, 네트워크 문제 등으로 인해 중복 요청이 발생해도 안전하게 처리할 수 있습니다.
   GET : 한번 조회하든, 두 번 조회하든 같은 결과가 조회됩니다 PUT : 전달받은 결과를 대체하기 때문에 같은 요청을 여러번 해도 최종 결과는 같습니다. POST : 멱등이 아닙니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있습니다.멱등은 자동 복구 메커니즘에 사용이 가능합니다. 그러나 외부 요인(다른사용자가 데이터를 변경한 후 PUT 한 경우)으로 중간에 리소스가 변경되는 것까지는 고려하지 않습니다.
   
   
3. 캐시 가능(Cacheable): 캐시 가능한 메서드는 응답 결과를 클라이언트나 중간 프록시 서버에 캐시할 수 있는 메서드입니다. GET, HEAD 메서드는 일반적으로 캐시 가능한 메서드입니다. 캐시 가능한 메서드는 동일한 요청에 대한 응답을 캐시에서 가져와 처리할 수 있으므로, 네트워크 대역폭을 줄이고 응답 속도를 향상시킬 수 있습니다. 응답 결과를 캐시에서 사용할 수 있는가!
   
   
4. 적절한 요청 본문(Well-Defined Request Body): 일부 메서드는 요청 본문에 데이터를 포함하여 서버에 전송할 수 있습니다. POST, PUT, PATCH 메서드는 요청 본문에 데이터를 포함할 수 있는 메서드입니다. 요청 본문은 클라이언트가 서버에 데이터를 제공하거나 업데이트할 때 사용됩니다.
   
   
5. 안전하지 않음(Unsafe): 안전하지 않은 메서드는 서버의 상태나 데이터를 변경할 수 있는 메서드입니다. POST, PUT, PATCH, DELETE 메서드는 안전하지 않은 메서드입니다. 이러한 메서드를 사용할 때는 주의해야 하며, 적절한 권한과 인증을 통해 보안을 유지해야 합니다.

🎈HTTP 메서드 활용

✅ 클라이언트에서 서버로 데이터 전송

• 쿼리 파라미터를 통한 데이터 전송
  쿼리 파라미터를 통한 데이터 전송은 간편하고 일반적으로 많이 사용되는 방식입니다. GET 에서 많이 사용하고 정렬 필터(검색어)를 사용할 때 사용합니다.하지만 보안에 민감한 정보(예: 비밀번호)는 URL에 노출되므로 주의해야 합니다. 민감한 정보를 전달해야 하는 경우에는 요청 본문이나 다른 전송 방식을 사용하는 것이 좋습니다.
  
  쿼리 파라미터(Query Parameters)를 통한 데이터 전송은 URL에 데이터를 포함하여 서버로 전달하는 방식입니다. 클라이언트는 URL의 끝에 ?를 추가하고, key=value 형식으로 데이터를 전달합니다. 여러 개의 쿼리 파라미터를 전달할 때는 &로 구분합니다.
  
  
• 메세지 바디를 통한 데이터 전송
  데이터를 HTTP 요청의 본문에 담아서 전달하는 방식입니다. 주로 POST, PUT, PATCH 메서드에서 사용됩니다. 클라이언트는 요청 본문에 데이터를 포함하고, 콘텐트 유형(Content-Type) 헤더를 통해 데이터의 형식(MIME 타입)을 지정합니다. 서버는 요청 본문을 읽어서 처리할 수 있습니다. 데이터의 형식에는 JSON, XML, 폼 데이터 등이 있습니다.
  
  클라이언트에서 서버로 데이터를 전송하는 4가지 상황
  1. 정적 데이터 조회 (쿼리 파라미터 미사용) : resource/path를 통해 전달 이미지나 정적 텍스트 문서를 전달할 때 주로 사용되며 , 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능합니다.
     
     
  2. 동적 데이터 조회( 쿼리파라미터 사용) : 주로 검색 or 게시판 목록에서 정렬 필터 (검색어) 추가 데이터들이 파라미터로 넘어갑니다. 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용합니다. 조회는 GET을 사용하며, GET은 쿼리 파라미터를 사용해서 데이터를 전달합니다.
     
     
  3. HTML 폼 데이터(Form Data): HTML 폼의 입력 필드에서 제출된 데이터를 전송하는 방식입니다. 폼 데이터는 application/x-www-form-urlencoded content-Type으로 전송됩니다. 클라이언트는 key=value 형식으로 데이터를 인코딩하여 요청 HTTP BODY(본문)에 포함시킵니다. 서버는 이러한 폼 데이터를 읽어서 처리할 수 있습니다. GET, POST만 지원합니다. 다른 Content-Type으로는 multipart/form-data 파일 업로드와 같은 바이너리 데이터 전송시 사용되며, 다른 종류의 여러 파일과 폼의 내용을 함께 전송이 가능합니다.
     
     
  4. HTML API 전송요청 본문에 데이터를 전송하는 경우에는 데이터의 형식에 따라 적절한 Content-Type 헤더를 설정해야 합니다. 일반적으로 JSON 데이터를 전송할 때는 Content-Type: application/json 헤더를 설정하고, 폼 데이터를 전송할 때는 Content-Type: application/x-www-form-urlencoded 헤더를 설정합니다.
     
     또한, HTTP API에서는 주로 JSON 형식으로 데이터를 주고받는 RESTful API가 많이 사용됩니다. JSON 형식은 데이터를 가볍고 구조화된 방식으로 전송할 수 있으며, 대부분의 프로그래밍 언어에서 JSON을 쉽게 처리할 수 있습니다.서버 to 서버로 데이터가 전송될 때 많이 사용되며 , 백엔드 시스템 통신의 경우입니다.
     
     앱 클라이언트 인 아이폰, 안드로이드에서 전송할 때도 사용합니다. 웹 클라이언트에서도 사용되는데, HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용됩니다. (AJAX) ex. React, VueJs 같은 웹 클라이언트와 API 통신을 합니다.
     
     

          
          <h3>로그인 : 아이디 비밀번호 입력</h3>
                <form method="post" action = "/save">
                    <!-- 입력된 userId를 저장할 수 있도록 하는 HTML FROM DATA 전송기법 -->
                    <label for = "userid"> 아이디 : </label>
                    <input type = "text" name = "id" id="userid"><br>
                </form> <br>

            ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
            웹 브라우저가 요청한 HTTP 메세지
            POST/save HTTP1/1.1
            Host: localhost:8080
            Content-Type : application/x-www.form-urlencoded

            userid=kim

HTTP는 다양한 메서드를 제공하여 클라이언트가 서버에 요청을 보내고, 서버는 해당 요청에 대한 응답을 반환합니다. 가장 널리 사용되는 HTTP 메서드는 다음과 같습니다

💡 요구사항 - 회원 정보 관리 API를 만들어라

API URI 설계 (URI : Uniform Resource Identifier)

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

ㅡㅡㅡㅡ 위의 리소스가 좋은 URI 설계일까?ㅡㅡㅡㅡ 가장 중요한 건 리소스 식별입니다.

리소스란 ❓

리소스(Resource)는 웹 애플리케이션에서 클라이언트가 요청하고 서버가 제공하는 데이터나 서비스를 의미합니다. 일반적으로 웹 애플리케이션에서 리소스는 웹 페이지, 이미지, 문서, 데이터베이스 레코드 등과 같은 것들을 포함합니다. 리소스는 고유한 식별자(예: URL)를 가지며, 클라이언트는 해당 식별자를 사용하여 리소스에 접근하고 요청할 수 있습니다.

리소스는 웹 애플리케이션의 중요한 구성 요소로, 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 대한 요청을 보냅니다. 서버는 이러한 요청을 처리하고, 적절한 응답을 반환하여 클라이언트에게 전달합니다. 이를 통해 클라이언트는 웹 애플리케이션에서 필요한 데이터를 조회, 생성, 업데이트, 삭제할 수 있습니다.

리소스는 일반적으로 웹 애플리케이션의 상태를 나타내는 정보를 포함하고, 클라이언트는 이러한 리소스를 조작하여 웹 애플리케이션의 동작을 제어하거나 데이터를 처리합니다. RESTful 웹 서비스의 경우 리소스는 RESTful API의 핵심 개념이며, 클라이언트는 URI(Uniform Resource Identifier)를 사용하여 리소스를 식별하고 조작합니다.

URI(Uniform Resource Identifier) 계층 구조는 리소스를 계층적으로 구성하여 효율적이고 일관성 있게 관리할 수 있는 방법을 제공합니다. URI 계층 구조는 다음과 같은 방식으로 활용될 수 있습니다:

1. 경로 구분: URI의 경로(Path)를 사용하여 리소스를 계층적으로 구분할 수 있습니다. 경로는 슬래시("/")로 구분되며, 각 경로 요소는 리소스의 상위 레벨을 의미합니다. 예를 들어, /users/john 경로는 "users"라는 상위 리소스 아래의 "john" 리소스를 식별합니다. 이러한 계층 구조를 활용하여 리소스를 조직화하고 접근할 수 있습니다.
   
   
2. 부모-자식 관계: URI의 계층 구조를 활용하여 부모-자식 관계를 표현할 수 있습니다. 예를 들어, /categories/books와 /categories/electronics와 같은 URI는 "categories"라는 부모 리소스 아래에 "books"와 "electronics"라는 자식 리소스를 가지고 있음을 나타냅니다. 이러한 관계를 활용하여 리소스 간의 상호작용을 나타내거나 필요한 데이터를 추출할 수 있습니다.
   
   
3. 컬렉션과 멤버: URI 계층 구조를 활용하여 컬렉션(Collection)과 멤버(Member)를 표현할 수 있습니다. 컬렉션은 여러 개의 리소스를 포함하는 상위 개념이고, 멤버는 개별 리소스를 나타냅니다. 예를 들어, /users는 사용자 컬렉션을, /users/{id}는 특정 사용자를 나타냅니다. 이러한 구조를 활용하여 컬렉션과 멤버 간의 관계를 표현하고 조작할 수 있습니다.
   
   
4. 상태 전이(State Transition): URI 계층 구조는 상태 전이(State Transition)를 표현하는 데에도 활용될 수 있습니다. RESTful API에서는 리소스 간의 상태 전이를 URI와 HTTP 메서드를 조합하여 표현합니다. 예를 들어, /orders/{id}/cancel은 특정 주문의 상태를 취소로 변경하는 상태 전이를 의미합니다. 이러한 URI 계층 구조를 통해 리소스의 상태 전이를 명확하게 표현하고 제어할 수 있습니다.
   
   

URI 계층 구조를 활용하여 리소스를 적절하게 조직하고 식별하는 것은 RESTful 아키텍처에서 중요한 개념입니다. 계층 구조를 일관성 있게 설계하고 사용하여 클라이언트가 리소스를 쉽게 찾고 조작할 수 있도록 지원할 수 있습니다.

URI(Uniform Resource Identifier) 설계 시 리소스 식별은 URI를 통해 고유한 리소스를 식별하는 것을 의미합니다. URI는 웹에서 리소스에 접근할 수 있는 주소로, 리소스를 고유하게 식별하기 위해 사용됩니다.

리소스 식별은 다음과 같은 원칙을 따라야 합니다:

1. 유일성: 각 리소스는 고유한 식별자를 가져야 합니다. 다른 리소스와 중복되지 않는 유니크한 식별자를 할당해야 합니다. 이를 통해 각각의 리소스가 독립적으로 식별되고 접근될 수 있습니다.
2. 명확성: 리소스 식별자는 클라이언트가 어떤 리소스에 접근하고 있는지 명확하게 알 수 있어야 합니다. 의미를 파악하기 쉬운 명시적인 식별자를 사용하는 것이 좋습니다.
   
   
3. 지속성: 리소스 식별자는 변하지 않는 것이 좋습니다. 리소스의 위치나 이름이 변경되지 않는 한, 동일한 식별자로 접근할 수 있어야 합니다. 이는 클라이언트가 항상 유효한 식별자를 사용하여 리소스에 접근할 수 있도록 보장합니다.

리소스 식별은 RESTful 아키텍처의 핵심 원칙 중 하나이며, 웹 애플리케이션에서 리소스를 효과적으로 관리하고 조작하기 위해 중요합니다. 클라이언트는 URI를 사용하여 원하는 리소스에 접근하고 RESTful API를 통해 해당 리소스를 조작할 수 있습니다. 따라서 URI 설계 시 리소스 식별은 명확하고 일관성 있게 이루어져야 합니다.

📕 HTTP 메서드

가장 널리 사용되는 HTTP 메서드는 다음과 같습니다:

1. GET : 서버로부터 리소스(데이터)를 가져오기 위해 사용되는 메서드입니다. 주로 데이터 조회나 검색에 사용됩니다. GET 요청은 주소 표시줄에 쿼리 매개변수로 데이터를 전달할 수 있습니다.
2. POST : 서버에 새로운 데이터를 전송하기 위해 사용되는 메서드입니다. 주로 데이터 생성이나 업데이트에 사용됩니다. POST 요청은 요청 본문에 데이터를 담아 서버로 전송합니다. 데이터를 담아서 클라이언트가 서버에 보내야 합니다.
3. PUT : 서버에 새로운 데이터를 전송하거나 기존 데이터를 업데이트하기 위해 사용되는 메서드입니다. PUT 요청은 요청 본문에 데이터를 담아 지정된 리소스를 대체합니다. 파일을 폴더에 넣는 것과 비슷합니다. 없으면 생성, 있으면 덮어씌어집니다.
4. DELETE : 서버에서 데이터를 삭제하기 위해 사용되는 메서드입니다. DELETE 요청은 지정된 리소스를 삭제합니다.
5. PATCH : 서버에 새로운 데이터를 부분적으로 업데이트하기 위해 사용되는 메서드입니다. PATCH 요청은 요청 본문에 업데이트할 데이터만 포함하며, 해당 리소스의 일부만 수정합니다.
6. HEAD : GET 요청과 유사하지만, 실제 데이터를 가져오지 않고 응답 헤더만 가져옵니다. 주로 리소스의 메타데이터를 확인할 때 사용됩니다.
7. OPTIONS : 서버가 지원하는 HTTP 메서드 목록을 요청합니다. 주로 CORS (Cross-Origin Resource Sharing) 정책을 확인하기 위해 사용됩니다.

✅ GET, POST

👉 GET 메서드 👈

HTTP 메서드 중 GET은 서버로부터 리소스를 요청하기 위해 사용되는 메서드입니다. GET 요청은 서버로부터 데이터를 가져오는 역할을 합니다. 일반적으로 GET 메서드는 조회에서만 사용하며 , 요청한 리소스를 가져와서 응답으로 반환하며, 서버의 상태나 데이터를 변경하지 않습니다.

GET 메서드는 주로 브라우저에서 웹 페이지나 이미지, 동영상 등을 요청할 때 사용됩니다. GET 요청은 URL에 데이터를 포함하여 전송할 수 있으며, 이러한 데이터는 쿼리 파라미터(Query Parameter)의 형태로 전달됩니다. 예를 들어, https://example.com/products?id=123와 같은 URL에서 id=123은 GET 요청에 대한 쿼리 파라미터입니다.

GET 메서드의 주요 특징은 다음과 같습니다:

• 요청한 리소스를 가져오기 위해 사용됨
• 데이터를 URL에 쿼리 파라미터로 전달
• 캐싱이 가능하므로 동일한 요청에 대한 반복적인 요청 시 서버 부하를 줄일 수 있음
• 요청에 대한 응답으로 데이터를 반환 (HTML, JSON, XML 등)

GET 메서드는 보안이나 데이터 변경과 관련된 작업에는 적합하지 않습니다. 데이터의 생성, 수정, 삭제 등을 요청하기 위해서는 다른 HTTP 메서드 (POST, PUT, DELETE 등)를 사용해야 합니다.

GET 메서드는 브라우저에서 주로 사용되지만, HTTP 클라이언트 라이브러리나 API 호출에서도 GET 메서드를 사용하여 서버로부터 데이터를 요청할 수 있습니다.

👉 POST메서드 👈

HTTP 메서드 중 POST는 클라이언트에서 서버로 데이터를 전송하기 위해 사용되는 메서드입니다. POST 요청은 서버에 새로운 리소스를 생성하거나 기존 리소스를 수정하기 위해 데이터를 전달합니다.

POST 메서드는 일반적으로 HTML 폼(form)을 통해 사용자로부터 입력 받은 데이터를 서버로 전송할 때 사용됩니다. 예를 들어, 회원 가입 폼이나 댓글 작성 폼에서 사용자가 입력한 데이터를 서버로 전송할 때 POST 요청을 사용합니다. POST 요청은 요청 본문(Request Body)에 데이터를 담아 전송하며, URL에는 데이터가 노출되지 않습니다.

POST 메서드의 주요 특징은 다음과 같습니다:

• 서버에 새로운 리소스를 생성하거나 기존 리소스를 수정하기 위해 사용 - 서버가 아직 식별하지 않은 새 리소스를 생성
• 요청에 대한 응답으로 생성된 리소스의 정보나 상태를 반환 - 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우 (ex) 상품 주문에서 → 결제 완료 → 배달 시작(배달시작 버튼을 누르는 것도 POST를 사용) → 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우 POST의 결과로 새로운 리소스가 생성되지 않을 수도 있습니다.
• 다른 메서드로 처리하기 어려운 경우 (ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우, 애매하면 POST를 사용

POST 메서드는 클라이언트가 서버에게 데이터를 전송하고, 서버는 해당 데이터를 처리하여 새로운 리소스를 생성하거나 기존 리소스를 변경하는 데 사용됩니다.
중요한 점은 POST 요청은 서버의 상태를 변경시키는 작업에 사용되므로, 이러한 작업을 수행할 때에는 적절한 권한과 보안 메커니즘이 필요합니다.

✅ PUT, PATCH, DELETE

👉 PUT 메서드 👈

PUT 메서드는 웹 서버에 새로운 리소스를 생성하거나 기존 리소스를 업데이트하는 데 사용됩니다. 클라이언트는 PUT 요청을 통해 서버에 데이터를 전송하고, 해당 데이터를 서버에 저장하거나 갱신할 수 있습니다. 쉽게 이야기하면 리소스를 대체하여 덮어씌워 버립니다.

PUT 요청은 일반적으로 RESTful API에서 자원을 생성하거나 업데이트하는 데 사용됩니다. 클라이언트는 PUT 요청을 보내면 원하는 자원의 위치(URI)와 업데이트할 데이터를 함께 전송합니다. 서버는 해당 위치에 자원을 생성하거나 업데이트하고, 작업 결과를 클라이언트에 응답합니다.

PUT 요청은 클라이언트가 전체 엔티티(리소스를 지정/식별)를 서버에 제공하는 것을 의미합니다. 따라서 클라이언트가 전체 리소스의 위치를 알고 URI를 지정하는 점이 POST와의 큰 차이점입니다. 전체 리소스의 내용을 PUT 요청 본문에 포함하여 서버에 전송해야 합니다. 이미 존재하는 리소스를 업데이트하는 경우에도 클라이언트는 전체 리소스를 제공해야 합니다. 그리고 요청한 리소스의 데이터로 기존 리소스들이 대체되어 데이터가 바뀌어버립니다.

PUT 메서드는 안전한 메서드로 간주되지 않습니다. 이는 서버의 상태나 데이터를 변경할 수 있기 때문입니다. 따라서 PUT 요청은 서버에 영향을 줄 수 있는 작업을 수행하기 때문에 주의해서 사용해야 합니다.

👉 PATCH 메서드 👈

리소스의 업데이트를 가능하게 해주는 메서드 입니다. PATCH 메서드는 서버에게 리소스의 부분적인 변경을 요청하는 데 사용됩니다. PUT 메서드를 사용하게되면 기존에 남아있던 리소스의 일부 변경이 아닌 전체가 대체되는데 이와 달리 PATCH메서드를 사용하게 되면 클라이언트는 전체 리소스를 보내지 않고도 리소스의 일부를 수정할 수 있습니다. 클라이언트는 PATCH 요청을 통해 변경하고자 하는 리소스의 일부를 지정하고, 서버는 해당 부분만 수정합니다. 이는 리소스의 일부를 효율적으로 업데이트할 수 있는 장점을 가지고 있습니다.

👉 DELETE 메서드 👈

DELETE 메서드는 서버에게 리소스의 삭제를 요청하는 데 사용됩니다. 클라이언트가 DELETE 요청을 보내면 서버는 해당 리소스를 삭제하고, 삭제 작업의 결과를 클라이언트에게 응답합니다. DELETE 요청을 통해 리소스를 삭제하면 해당 리소스에 대한 접근이 불가능해지며, 서버에서 완전히 제거됩니다.