DevOps 8일차 - HTTP 기초

문한성·2023년 3월 16일

devops

부트캠프

목록 보기

12/123

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

문한성

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

이전 포스트

DevOps 7일차 - 웹서비스 접근하기(예습)

다음 포스트