[Web] HTTP 메서드 (Method) 정리

동긔·2024년 9월 25일

Web

목록 보기

2/4

1. HTTP 메서드 (Method)란?

1.1 HTTP 메서드의 정의

HTTP 메서드는 클라이언트(사용자)가 서버에 요청을 보낼 때 사용하는 방식입니다. 이 메서드를 통해 클라이언트는 서버에서 정보를 조회하거나 데이터를 전송하는 등의 작업을 할 수 있습니다. HTTP 메서드는 서버와 클라이언트 간의 상호작용을 어떻게 할지를 정의합니다.

1.2 HTTP 메서드의 역할

HTTP 메서드는 클라이언트가 어떤 작업을 서버에게 요청하는지를 명확하게 전달하는 수단입니다. 이를 통해 웹 애플리케이션에서 다양한 데이터 처리 작업이 이루어집니다. 예를 들어, 데이터를 서버로 보내거나, 서버에 있는 데이터를 가져오는 것 등이 가능합니다.

2. HTTP 메서드 종류

HTTP 메서드는 다양한 종류가 있으며, 각각은 특정한 동작을 정의합니다. HTTP 주요 메서드에는 GET, POST, PUT, DELET, PATCH가 있고 HTTP 기타 메서드에는 HEAD, OPTIONS, TRACE, CONNECT가 있습니다.

2.1 GET

GET 메서드는 서버에서 데이터를 조회할 때 사용됩니다. 주로 서버에서 데이터를 가져오고, 서버에 변경 사항을 발생시키지 않습니다. 예를 들어, 웹페이지를 로드할 때 사용됩니다.

1) 흐름 및 예시

클라이언트가 GET 요청을 보냄: 클라이언트는 필요한 데이터가 있을 경우 서버로 GET 요청을 보냅니다.
서버에서 데이터 처리: 서버는 요청된 자원(예: 데이터베이스의 데이터)을 조회합니다.
서버가 응답: 서버는 클라이언트에 데이터를 포함한 응답을 반환합니다.

GET /users/1 HTTP/1.1
Host: example.com

이 요청은 example.com 서버에서 사용자 ID가 1인 사용자의 데이터를 가져오는 요청입니다.

2.2 POST

POST 메서드는 클라이언트에서 서버로 데이터를 보낼 때 사용됩니다. 주로 새로운 리소스를 생성하거나, 서버에 데이터를 추가할 때 사용됩니다.

1) 흐름 및 예시

클라이언트가 POST 요청을 보냄: 클라이언트는 새 데이터를 서버로 전송하기 위해 POST 요청을 보냅니다.
서버에서 데이터 처리: 서버는 해당 데이터를 처리하여 데이터베이스에 저장하거나 리소스를 생성합니다.
서버가 응답: 서버는 새로 생성된 리소스에 대한 응답을 반환합니다.

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

{
  "name": "John Doe",
  "email": "john@example.com"
}

이 요청은 example.com 서버에 새로운 사용자를 추가하는 요청입니다.

2.3 PUT

PUT 메서드는 서버에서 리소스를 업데이트할 때 사용됩니다. 주어진 데이터로 리소스를 대체하거나, 리소스가 없으면 새로 생성합니다.

1) 흐름 및 예시

클라이언트가 PUT 요청을 보냄: 클라이언트는 업데이트할 리소스를 서버에 전송합니다.
서버에서 데이터 처리: 서버는 해당 리소스를 기존 데이터와 교체하거나, 새로 생성합니다.
서버가 응답: 서버는 업데이트된 리소스에 대한 응답을 반환합니다.

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

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

이 요청은 사용자 ID가 1인 사용자의 데이터를 업데이트하는 요청입니다.

2.4 DELETE

DELETE 메서드는 서버에서 리소스를 삭제할 때 사용됩니다. 주로 데이터베이스에서 특정 데이터를 제거하는 데 사용됩니다.

1) 흐름 및 예시

클라이언트가 DELETE 요청을 보냄: 클라이언트는 삭제할 리소스에 대해 서버에 DELETE 요청을 보냅니다.
서버에서 데이터 처리: 서버는 해당 리소스를 삭제합니다.
서버가 응답: 서버는 삭제 완료에 대한 응답을 반환합니다.

DELETE /users/1 HTTP/1.1
Host: example.com

이 요청은 example.com 서버에서 사용자 ID가 1인 사용자를 삭제하는 요청입니다.

2.5 PATCH

PATCH 메서드는 리소스의 일부만 업데이트할 때 사용됩니다. PUT과는 달리 전체 리소스를 교체하지 않고, 일부 필드만 변경할 때 사용됩니다.

1) 흐름 및 예시

클라이언트가 PATCH 요청을 보냄: 클라이언트는 변경할 데이터만 포함하여 서버에 PATCH 요청을 보냅니다.
서버에서 데이터 처리: 서버는 해당 리소스의 일부만 변경합니다.
서버가 응답: 서버는 변경된 리소스에 대한 응답을 반환합니다.

PATCH /users/1 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "email": "newemail@example.com"
}

이 요청은 사용자 ID가 1인 사용자의 이메일 주소만 업데이트하는 요청입니다.

2.6 HEAD

HEAD 메서드는 GET 메서드와 거의 동일하지만, 응답 본문(body)을 반환하지 않습니다. 주로 리소스의 존재 여부나 상태를 확인하는 데 사용됩니다.

1) 흐름 및 예시

클라이언트가 HEAD 요청을 보냄: 클라이언트는 리소스의 상태나 존재 여부를 확인하기 위해 HEAD 요청을 보냅니다.
서버에서 데이터 처리: 서버는 GET 요청처럼 해당 리소스를 조회하지만, 본문을 반환하지 않습니다.
서버가 응답: 서버는 헤더 정보(상태 코드, 콘텐츠 길이 등)만 반환합니다.

HEAD /users/1 HTTP/1.1
Host: example.com

이 요청은 example.com 서버에 사용자 ID가 1인 사용자가 있는지 확인하는 요청입니다. 응답 본문 없이 헤더 정보만 반환됩니다.

2) 활용 예시

캐싱: 클라이언트는 GET 요청 전에 HEAD 요청을 보내서 리소스가 변경되었는지 확인하고, 캐시된 데이터를 사용할 수 있는지 결정할 수 있습니다.
리소스 확인: 서버에 있는 특정 리소스의 존재 여부를 확인할 때 사용됩니다.

2.7 OPTIONS

OPTIONS 메서드는 서버가 지원하는 메서드의 종류를 확인할 때 사용됩니다. 특정 리소스에 대해 서버가 허용하는 HTTP 메서드를 조회하는 데 유용합니다.

1) 흐름 및 예시

클라이언트가 OPTIONS 요청을 보냄: 클라이언트는 서버에서 특정 리소스에 대해 어떤 메서드가 가능한지 알아보기 위해 OPTIONS 요청을 보냅니다.
서버에서 데이터 처리: 서버는 해당 리소스에 대해 가능한 HTTP 메서드 목록을 조회합니다.
서버가 응답: 서버는 가능한 메서드 목록을 포함한 응답을 반환합니다.

OPTIONS /users/1 HTTP/1.1
Host: example.com

이 요청은 example.com 서버에서 사용자 ID가 1인 리소스에 대해 지원되는 HTTP 메서드를 확인하는 요청입니다.

2) 활용 예시

CORS(교차 출처 리소스 공유) 처리: 브라우저는 다른 도메인으로 요청을 보내기 전에 OPTIONS 요청을 통해 해당 도메인에서 허용하는 메서드를 확인합니다.
API 문서화: 서버에서 어떤 HTTP 메서드가 특정 리소스에 적용 가능한지 확인할 때 유용합니다.

2.8 TRACE

TRACE 메서드는 클라이언트와 서버 사이의 경로를 추적하는 데 사용됩니다. 요청이 서버로 전달되는 과정을 확인할 수 있어, 네트워크 문제를 디버깅하는 데 유용합니다.

1) 흐름 및 예시

클라이언트가 TRACE 요청을 보냄: 클라이언트는 네트워크 경로의 추적을 위해 TRACE 요청을 보냅니다.
서버에서 데이터 처리: 서버는 요청이 서버에 도달하기까지의 경로를 추적합니다.
서버가 응답: 서버는 클라이언트가 보낸 요청 메시지를 그대로 반환합니다.

TRACE /users/1 HTTP/1.1
Host: example.com

이 요청은 example.com 서버로 전달되는 경로를 추적하고, 그 결과를 클라이언트에게 반환합니다.

2) 활용 예시

네트워크 디버깅: 클라이언트와 서버 사이에 발생하는 네트워크 문제를 추적하고 해결할 때 사용됩니다.
보안 리스크: TRACE 요청은 잠재적으로 보안에 취약할 수 있어, 많은 서버에서 비활성화하는 것이 일반적입니다.

2.9 CONNECT

CONNECT 메서드는 클라이언트가 서버에 터널을 설정하는 데 사용됩니다. 주로 HTTPS와 같은 보안 연결을 만들기 위해 프록시 서버에서 사용됩니다.

1) 흐름 및 예시

클라이언트가 CONNECT 요청을 보냄: 클라이언트는 프록시 서버를 통해 보안 연결을 요청합니다.
프록시 서버에서 터널 설정: 프록시 서버는 클라이언트와 원본 서버 간의 터널을 설정합니다.
터널을 통한 통신: 설정된 터널을 통해 클라이언트와 서버는 보안 연결을 유지하며 데이터를 주고받습니다.

CONNECT example.com:443 HTTP/1.1
Host: example.com

이 요청은 클라이언트가 프록시 서버를 통해 example.com과의 HTTPS 연결을 설정하는 요청입니다.

2) 활용 예시

HTTPS 요청: 클라이언트가 프록시 서버를 통해 HTTPS 연결을 설정할 때 사용됩니다.
프록시 터널링: 방화벽이나 네트워크 경계를 넘어 보안 연결을 할 때 유용합니다.

3. HTTP 메서드의 속성

HTTP 메서드는 각각의 성질에 따라 서버의 동작에 영향을 미칩니다. 이 성질들은 애플리케이션의 성능, 안정성, 보안에 중요한 영향을 미치므로 이해하는 것이 매우 중요합니다.

3.1 안전성 (Safe Methods)

안전한 메서드(Safe Methods)는 서버의 상태를 변경하지 않는 메서드를 의미합니다. 즉, 이 메서드를 여러 번 호출하더라도 서버의 상태나 데이터가 변경되지 않아야 합니다.

GET: 가장 대표적인 안전한 메서드입니다. 서버에서 데이터를 가져오지만, 서버의 상태는 그대로 유지됩니다. 웹페이지를 요청하거나 데이터를 조회할 때 주로 사용합니다. 예시: 사용자가 GET /users/1 요청을 보낼 경우, 서버는 사용자 정보만 조회할 뿐, 실제 데이터는 변경되지 않습니다.
HEAD: GET과 비슷하게 리소스의 상태를 조회하지만, 본문을 제외한 헤더 정보만 반환하는 메서드입니다. 데이터 변경 없이 상태 확인을 위해 사용됩니다. 예시: HEAD /users/1 요청은 리소스의 헤더만 반환합니다. 데이터를 변경하지 않고 리소스의 존재 여부를 확인할 수 있습니다.

안전성은 서버의 데이터 보존 및 무결성을 유지하는 데 중요한 속성입니다. 안전한 메서드는 로그 조회, 리소스 확인 등 서버의 변경 없이 정보를 확인할 때 사용됩니다.

3.2 멱등성 (Idempotent Methods)

멱등한 메서드(Idempotent Methods)는 동일한 요청을 여러 번 보내더라도 서버의 상태나 결과가 변하지 않는 메서드를 의미합니다. 즉, 동일한 요청을 반복적으로 보내더라도 서버에서 동일한 결과가 나오게 됩니다.

GET: 멱등성을 가진 메서드입니다. 서버에서 데이터를 조회만 하기 때문에 여러 번 요청을 보내더라도 서버 상태에는 영향을 미치지 않습니다. 예시: GET /users/1을 10번 호출하더라도, 서버는 동일한 사용자 정보를 반환하며 상태가 변하지 않습니다.
PUT: 리소스를 업데이트하거나, 없다면 새로 생성하는 메서드입니다. 동일한 요청을 여러 번 보내더라도 동일한 결과를 보장합니다. 예시: PUT /users/1 요청으로 사용자 정보를 업데이트할 때, 같은 요청을 여러 번 보내더라도 최종 결과는 동일한 사용자 정보로 유지됩니다.
DELETE: 리소스를 삭제하는 메서드입니다. 여러 번 요청을 보내더라도 해당 리소스가 삭제된 이후에는 결과가 동일하게 유지됩니다. 예시: DELETE /users/1 요청을 두 번 보냈을 경우, 첫 번째 요청에서 리소스가 삭제되고, 두 번째 요청에서는 더 이상 해당 리소스가 없다는 응답을 받게 됩니다.

멱등성은 서버의 안정성을 보장하고, 네트워크 오류로 인한 중복 요청이 발생하더라도 시스템이 일관성을 유지할 수 있도록 합니다.

3.3 캐시 가능성 (Cacheable Methods)

캐시 가능 메서드(Cacheable Methods)는 클라이언트가 응답을 캐시에 저장할 수 있는 메서드를 의미합니다. 이를 통해 클라이언트는 서버에 불필요한 요청을 보내지 않고, 캐시된 데이터를 활용할 수 있습니다.

GET: 가장 대표적으로 캐시 가능한 메서드입니다. 서버에서 조회한 데이터를 클라이언트가 캐시에 저장해, 동일한 요청에 대해 서버에 다시 요청하지 않고 캐시된 데이터를 사용할 수 있습니다. 예시: GET /users/1 요청을 보낸 후, 클라이언트는 사용자 데이터를 캐시에 저장할 수 있습니다. 이후 동일한 요청을 보낼 경우 서버로 요청을 보내지 않고 캐시된 데이터를 바로 반환할 수 있습니다.
HEAD: GET과 유사하게 캐시 가능하지만, 본문이 없기 때문에 헤더 정보만 캐시됩니다.
POST: 일반적으로 캐시되지 않지만, 일부 경우에 서버에서 POST 응답을 캐시할 수 있습니다. 다만, POST는 서버에서 리소스를 생성하거나 데이터를 변경할 수 있기 때문에 캐시가 잘 사용되지 않는 메서드입니다.

캐시 가능성은 네트워크 성능 최적화와 응답 시간 단축에 중요한 요소로, GET과 같은 조회 요청에서 자주 사용됩니다.

4. HTTP 상태코드란?

HTTP 상태코드는 서버가 클라이언트의 요청에 대한 응답으로 보내는 3자리 숫자 코드입니다. 이를 통해 클라이언트는 요청이 성공적으로 처리되었는지, 오류가 발생했는지, 혹은 추가 작업이 필요한지 알 수 있습니다. 상태 코드는 5가지 범주로 나뉩니다.

1xx: 정보 제공(Informational)
2xx: 성공(Success)
3xx: 리다이렉션(Redirection)
4xx: 클라이언트 오류(Client Error)
5xx: 서버 오류(Server Error)

상태 코드는 클라이언트와 서버 간의 통신에서 매우 중요한 역할을 하며, 특히 오류 처리와 요청의 성공 여부를 파악하는 데 도움이 됩니다.

5. HTTP 상태코드 종류

5.1 1xx: 정보 응답

1xx 상태 코드는 요청을 처리 중이거나, 클라이언트가 더 많은 정보를 제공해야 한다는 의미를 담고 있습니다.

100 Continue: 클라이언트가 보낸 요청의 초기 부분을 서버가 확인했으며, 나머지 요청을 계속 진행해도 좋다는 응답입니다. 예시: 클라이언트가 대용량 파일을 업로드하는 중에 서버가 100 Continue 응답을 보내면, 클라이언트는 나머지 데이터를 계속해서 전송할 수 있습니다.

5.2 2xx: 성공 응답

2xx 상태 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타냅니다.

200 OK: 가장 일반적인 성공 응답 코드로, 요청이 정상적으로 처리되었음을 의미합니다. 조회, 업데이트, 삭제 등의 요청이 성공했을 때 반환됩니다. 예시: GET /users/1 요청이 성공적으로 처리되면, 서버는 사용자 데이터를 반환하고 200 OK 상태 코드를 함께 보냅니다.
201 Created: 클라이언트의 요청으로 새로운 리소스가 생성되었음을 의미합니다. 주로 POST 요청에 대한 응답으로 사용됩니다. 예시: POST /users 요청으로 새로운 사용자가 생성되면, 서버는 201 Created 상태 코드와 함께 생성된 리소스의 URL을 반환할 수 있습니다.

5.3 3xx: 리다이렉션

3xx 상태 코드는 클라이언트가 요청한 리소스가 다른 위치로 이동되었거나, 추가 작업이 필요함을 나타냅니다.

301 Moved Permanently: 요청한 리소스가 영구적으로 새로운 URL로 이동되었음을 의미합니다. 클라이언트는 앞으로 새로운 URL로 요청을 보내야 합니다. 예시: 예전 웹사이트가 새로운 도메인으로 옮겨졌을 때, 서버는 301 Moved Permanently 응답을 보내어 클라이언트가 새 URL로 이동할 수 있도록 유도합니다.
302 Found: 요청한 리소스가 일시적으로 다른 URL에 있음을 나타냅니다. 클라이언트는 임시로 다른 URL에서 리소스를 받아야 하지만, 나중에는 원래 URL을 다시 사용할 수 있습니다. 예시: 서버에서 일시적인 유지 보수가 진행 중일 때, 클라이언트는 302 Found 응답을 받아 임시 페이지로 리다이렉트될 수 있습니다.

5.4 4xx: 클라이언트 오류

4xx 상태 코드는 클라이언트의 요청에 문제가 있을 때 반환됩니다. 주로 요청의 형식 오류나, 인증 문제 등이 발생할 때 사용됩니다.

400 Bad Request: 요청이 잘못되었거나 형식이 올바르지 않을 때 반환됩니다. 잘못된 파라미터, 부정확한 데이터 구조 등이 원인이 될 수 있습니다. 예시: 클라이언트가 POST /users 요청에서 필수 필드를 빠뜨렸을 경우, 서버는 400 Bad Request 상태 코드를 반환할 수 있습니다.
401 Unauthorized: 요청을 처리하기 위해서는 클라이언트가 인증을 해야 함을 의미합니다. 인증 정보가 없거나, 잘못된 인증을 제공했을 때 반환됩니다. 예시: 클라이언트가 보호된 API에 접근하려 할 때, 적절한 인증 토큰이 없으면 서버는 401 Unauthorized 응답을 보냅니다.
404 Not Found: 요청한 리소스를 찾을 수 없음을 의미합니다. 클라이언트가 요청한 URL이 잘못되었거나, 해당 리소스가 존재하지 않을 때 반환됩니다. 예시: GET /users/999 요청에서 사용자 ID 999번이 존재하지 않으면, 서버는 404 Not Found 상태 코드를 반환합니다.

5.5 5xx: 서버 오류

5xx 상태 코드는 서버에서 오류가 발생하여 요청을 처리하지 못했음을 나타냅니다. 클라이언트 측 문제가 아닌 서버 자체의 문제로 인해 발생합니다.

500 Internal Server Error: 서버에서 내부 오류가 발생하여 요청을 처리할 수 없을 때 반환됩니다. 코드 오류, 서버 설정 문제 등이 원인이 될 수 있습니다. 예시: 서버에서 예외 처리 코드가 잘못되어 오류가 발생하면, 500 Internal Server Error 상태 코드가 반환될 수 있습니다.
503 Service Unavailable: 서버가 현재 요청을 처리할 수 없는 상태일 때 반환됩니다. 서버 과부하, 유지 보수 중일 때 주로 사용됩니다. 예시: 서버가 과도한 트래픽으로 인해 응답할 수 없는 경우, 503 Service Unavailable 상태 코드가 반환됩니다.

동긔

배우고 느낀점들을 기록합니다. 열정 넘치는 백엔드 개발자로 남고싶습니다.

[Web] HTTP 메서드 (Method) 정리

Web

1. HTTP 메서드 (Method)란?

1.1 HTTP 메서드의 정의

1.2 HTTP 메서드의 역할

2. HTTP 메서드 종류

2.1 GET

1) 흐름 및 예시

2.2 POST

1) 흐름 및 예시

2.3 PUT

1) 흐름 및 예시

2.4 DELETE

1) 흐름 및 예시

2.5 PATCH

1) 흐름 및 예시

2.6 HEAD

1) 흐름 및 예시

2) 활용 예시

2.7 OPTIONS

1) 흐름 및 예시

2) 활용 예시

2.8 TRACE

1) 흐름 및 예시

2) 활용 예시

2.9 CONNECT

1) 흐름 및 예시

2) 활용 예시

3. HTTP 메서드의 속성

3.1 안전성 (Safe Methods)

3.2 멱등성 (Idempotent Methods)

3.3 캐시 가능성 (Cacheable Methods)

4. HTTP 상태코드란?

5. HTTP 상태코드 종류

5.1 1xx: 정보 응답

5.2 2xx: 성공 응답

5.3 3xx: 리다이렉션

5.4 4xx: 클라이언트 오류

5.5 5xx: 서버 오류

[Web] 웹소켓 (WebSocket) 개념 정리

[Web] API 버전 관리 정리

0개의 댓글