DevOps 8일차 - HTTP 기초

문한성·2023년 3월 16일
0

부트캠프

목록 보기
12/123
post-thumbnail

HTTP헤더, 요청과 응답

https://hansungmoon.github.io/HTTP6/

HTTP 헤더는 HTTP 요청 및 응답과 함께 전송되는 추가 정보입니다. 이러한 헤더는 콘텐츠 유형, 인코딩, 캐싱 지시문, 인증 정보 등과 같이 전송되는 데이터에 대한 중요한 정보를 제공합니다.

HTTP 헤더는 요청 헤더와 응답 헤더의 두 가지 범주로 나눌 수 있습니다.

요청 헤더:

요청 헤더는 요청에 대한 추가 정보를 제공하기 위해 클라이언트(예: 웹 브라우저)에서 서버로 전송됩니다. 몇 가지 일반적인 요청 헤더는 다음과 같습니다.

  • User-Agent: 이 헤더는 웹 브라우저나 모바일 앱과 같이 요청을 하는 클라이언트 애플리케이션을 식별합니다. 이를 통해 서버는 해당 클라이언트에 최적화된 콘텐츠를 제공할 수 있습니다.
  • 수락: 이 헤더는 HTML, JSON 또는 XML과 같이 클라이언트가 수락할 수 있는 콘텐츠 유형을 서버에 알려줍니다.
  • Authorization: 이 헤더에는 서버가 클라이언트의 요청을 확인하는 데 사용할 수 있는 인증 정보가 포함되어 있습니다.
  • Cache-Control: 이 헤더는 서버에 응답을 캐시할지 여부와 캐시할 경우 캐시 기간을 알려줍니다.
  • 쿠키: 이 헤더에는 클라이언트가 이전에 서버에서 받은 쿠키가 포함되어 있어 서버가 요청 간에 상태를 유지할 수 있습니다.

응답 헤더:

응답 헤더는 전송되는 응답에 대한 추가 정보를 제공하기 위해 서버에서 전송됩니다. 일반적인 응답 헤더는 다음과 같습니다.

  • Content-Type: 이 헤더는 HTML, JSON 또는 XML과 같이 전송되는 콘텐츠 유형을 클라이언트에 알려줍니다.
  • Content-Length: 이 헤더는 클라이언트에게 전송되는 콘텐츠의 길이를 바이트 단위로 알려줍니다.
  • Cache-Control: 이 헤더는 클라이언트에게 응답을 캐시할지 여부와 캐시할 경우 캐시 기간을 알려줍니다.
  • Set-Cookie: 이 헤더는 클라이언트 시스템에 쿠키를 설정하여 서버가 요청 간에 상태를 유지할 수 있도록 합니다.
  • 위치: 이 헤더는 요청된 리소스를 찾을 위치를 클라이언트에 알리기 위해 리디렉션에 사용됩니다.

전반적으로 HTTP 헤더는 클라이언트와 서버 간의 통신에서 중요한 역할을 하여 보다 효율적이고 효과적인 데이터 전송을 가능하게 합니다.

요청 헤더 예:

사용자가 웹 브라우저의 주소 표시줄에 "http://www.example.com"을 입력하고 Enter 키를 누른다고 가정해 보겠습니다. 그런 다음 브라우저는 여러 요청 헤더와 함께 "www.example.com"의 서버에 HTTP 요청을 보냅니다. 다음은 이러한 헤더의 모양에 대한 예입니다.

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

이 예에서 요청의 첫 번째 줄은 HTTP 메서드(GET)이고 그 뒤에는 요청된 리소스("/")와 HTTP 버전(HTTP/1.1)이 있습니다. "Host" 헤더는 요청이 어떤 도메인 이름인지 서버에 알려줍니다. "User-Agent" 헤더는 요청하는 브라우저를 식별합니다. "Accept" 헤더는 브라우저가 허용할 수 있는 콘텐츠 유형을 서버에 알려줍니다. 마지막으로 "Accept-Encoding" 헤더는 브라우저가 처리할 수 있는 인코딩 방법을 서버에 알려주고 "Connection" 헤더는 요청이 완료된 후 연결을 유지해야 하는지 아니면 닫아야 하는지 서버에 알려줍니다.

응답 헤더 예:

서버는 요청을 받은 후 자체 헤더 세트와 함께 HTTP 응답을 다시 보냅니다. 다음은 이러한 헤더의 모양에 대한 예입니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1153
Cache-Control: max-age=86400
Expires: Wed, 17 Mar 2023 00:00:00 GMT
Server: Apache

이 예에서 응답의 첫 번째 줄에는 HTTP 버전, 상태 코드(200 OK) 및 이유 문구가 포함됩니다. "Content-Type" 헤더는 어떤 유형의 콘텐츠가 다시 전송되는지 브라우저에 알려줍니다(이 경우 문자 집합이 UTF-8인 text/html). "Content-Length" 헤더는 예상되는 콘텐츠의 바이트 수를 브라우저에 알려줍니다. "Cache-Control" 헤더는 브라우저에 응답을 캐시할지 여부와 캐시할 경우 캐시 기간(이 경우 86400초 또는 1일)을 알려줍니다. "Expires" 헤더는 "Cache-Control"과 유사하지만 응답이 만료되어야 하는 정확한 시간과 날짜를 제공합니다. 마지막으로 "Server" 헤더는 요청을 처리하는 데 사용되는 웹 서버 소프트웨어를 브라우저에 알려줍니다.

발표자료

HTTP의 메소드와 CRUD(create/read/update/delete)를 적절하게 짝짓고, POST와 PUT의 차이점을 설명하세요.

CRUD는 Create, Read, Update, Delete의 약자입니다. 데이터베이스 또는 API의 기본 기능을 설명하는 일반적인 방법입니다. 이러한 작업은 다음과 같이 HTTP 메서드에 해당합니다.

  • Create: HTTP POST 방식에 해당
  • Read: HTTP GET 방식에 해당
  • Update: HTTP PUT 또는 PATCH 방식에 해당
  • Delete: HTTP DELETE 방식에 해당

POST 및 PUT 메서드는 모두 리소스를 생성하거나 업데이트하는 데 사용되지만 둘 사이에는 몇 가지 중요한 차이점이 있습니다.

POST 방법:

POST 메서드는 일반적으로 서버에서 새 리소스를 만드는 데 사용됩니다. 클라이언트가 POST 요청을 보내면 서버는 고유 식별자를 사용하여 새 리소스를 만들고 해당 식별자를 응답으로 클라이언트에 반환합니다. 그런 다음 클라이언트는 해당 식별자를 사용하여 나중에 리소스에 액세스하거나 수정할 수 있습니다.

예를 들어 블로그 플랫폼용 API를 구축하는 경우 POST 요청을 사용하여 요청 본문에 다음 데이터가 포함된 새 블로그 게시물을 만들 수 있습니다.

POST /posts HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "My First Blog Post",
  "content": "This is the content of my first blog post."
}

그런 다음 서버는 고유 식별자(예: /posts/1)를 사용하여 새 리소스를 생성하고 해당 식별자를 응답으로 클라이언트에 반환합니다.

PUT 방법:

PUT 메서드는 일반적으로 서버의 기존 리소스를 업데이트하는 데 사용됩니다. 클라이언트가 PUT 요청을 보낼 때 변경되었을 수 있는 모든 필드를 포함하여 요청 본문에 리소스의 완전한 표현을 포함합니다. 그런 다음 서버는 기존 리소스를 요청에 제공된 새 표현으로 바꿉니다.

업데이트하는데 Post도 사용이 가능하지만 Put을 쓰는 이유는 멱등성 때문이다.

예를 들어 이전 예제에서 만든 블로그 게시물을 업데이트하려는 경우 요청 본문에 다음 데이터가 포함된 PUT 요청을 사용합니다.

PUT /posts/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "My First Blog Post (Updated)",
  "content": "This is the updated content of my first blog post."
}

이 예에서 서버는 요청 본문에 제공된 새 데이터로 기존 리소스(/posts/1로 식별됨)를 업데이트합니다.

요약하면 POST 메서드는 새 리소스를 만드는 데 사용되고 PUT 메서드는 기존 리소스를 업데이트하는 데 사용됩니다. API가 올바르고 효율적인지 확인하려면 각 작업에 올바른 방법을 사용하는 것이 중요합니다.

HTTP 응답 코드의 200, 300, 400, 500번대의 특징과 차이점을 설명하세요.

https://hansungmoon.github.io/HTTP5/

HTTP 응답 코드는 HTTP 요청의 상태를 나타내는 세 자리 숫자입니다. 다음과 같은 5가지 클래스로 그룹화됩니다.

  • 1xx: 정보용
  • 2xx: 성공
  • 3xx: 리디렉션
  • 4xx: 클라이언트 오류
  • 5xx: 서버 오류

다음은 다양한 HTTP 응답 코드 클래스의 특징과 차이점입니다.

2xx 성공:

2xx 클래스의 HTTP 응답 코드는 요청이 성공했음을 나타냅니다. 가장 일반적인 2xx 응답 코드는 200이며, 이는 요청이 성공했고 서버가 요청된 콘텐츠를 반환하고 있음을 의미합니다. 기타 2xx 응답 코드는 다음과 같습니다.

  • 201 Created: 요청이 이행되었으며 새 리소스가 생성되었습니다.
  • 204 콘텐츠 없음: 요청에 성공했지만 반환할 콘텐츠가 없습니다.

3xx 리디렉션:

3xx 클래스의 HTTP 응답 코드는 클라이언트가 요청을 완료하기 위해 추가 단계를 수행해야 함을 나타냅니다. 가장 일반적인 3xx 응답 코드는 302 Found이며 요청된 리소스가 일시적으로 새 URL로 이동했음을 나타냅니다. 기타 3xx 응답 코드는 다음과 같습니다.

  • 301 영구적으로 이동됨: 요청한 리소스가 새 URL로 영구적으로 이동되었습니다.
  • 304 수정되지 않음: 요청된 리소스가 마지막으로 액세스된 이후 변경되지 않았으므로 서버가 캐시된 버전을 반환하고 있습니다.

4xx 클라이언트 오류:

4xx 클래스의 HTTP 응답 코드는 클라이언트가 만든 요청에 오류가 있음을 나타냅니다. 가장 일반적인 4xx 응답 코드는 400 잘못된 요청입니다. 이는 요청 형식이 잘못되었고 서버가 이를 이해할 수 없음을 의미합니다. 기타 4xx 응답 코드는 다음과 같습니다.

  • 401 권한 없음: 클라이언트가 요청된 리소스에 액세스하려면 유효한 인증 자격 증명을 제공해야 합니다.
  • 404 찾을 수 없음: 요청한 리소스가 서버에 없습니다.

5xx 서버 오류:

5xx 클래스의 HTTP 응답 코드는 요청을 처리하는 서버에 오류가 있음을 나타냅니다. 가장 일반적인 5xx 응답 코드는 500 내부 서버 오류입니다. 이는 서버에 오류가 발생하여 요청을 이행할 수 없음을 의미합니다. 기타 5xx 응답 코드는 다음과 같습니다.

  • 503 서비스를 사용할 수 없음: 요청을 처리하기 위해 서버를 일시적으로 사용할 수 없습니다.
  • 504 게이트웨이 시간 초과: 게이트웨이 또는 프록시 역할을 하는 서버가 업스트림 서버로부터 적시에 응답을 받지 못했습니다.

요약하면 HTTP 응답 코드는 HTTP 요청의 상태를 나타내는 데 사용됩니다. 다양한 응답 코드 클래스는 성공적인 요청에서 요청 이행을 방해하는 클라이언트 또는 서버 오류에 이르기까지 다양한 유형의 오류 또는 성공을 나타냅니다.

profile
기록하고 공유하려고 노력하는 DevOps 엔지니어

0개의 댓글