HTTP 응답코드 메소드 정리 GET, POST, PUT, PATCH, DELETE, TRACE, OPTIONS
- JAVA/프로그래밍 이론
- 2018. 5. 1. 00:59
HTTP Request 정보
GET /index.html HTTP/1.1 | 요청 URL정보 (Mehotd /URI HTTP버젼) |
user-agent: MSIE 6.0; Window NT 5.0 | 사용자 웹 브라우져 종류 |
accept: test/html; */* | 요청 데이터 타입 (응답의 Content-type과 유사) |
cookie:name=value | 쿠키(인증 정보) |
refere: http://abc.com | 경유지 URL |
host: www.abc.com | 요청 도메인 |
HTTP Response 정보
HTTP/1.1 200 OK | 프로토콜 버젼 및 응답코드 |
Server: Apache | 웹 서버 정보 |
Content-type: text/html | MIME 타입 |
Content-length : 1593 | HTTP BODY 사이즈 |
<html><head>..... | HTTP BODY 컨텐츠 |
HTTP 응답코드
응답대역 | 응답코드 |
설명 |
정보전송 임시응답 | 100 |
Continue (클라이언트로 부터 일부 요청을 받았으며 나머지 정보를 계속 요청함) |
101 |
Switching protocols |
|
성공 | 200 |
OK(요청이 성공적으로 수행되었음 |
201 |
Created (PUT 메소드에 의해 원격지 서버에 파일 생성됨) |
|
202 |
Accepted(웹 서버가 명령 수신함) |
|
203 |
Non-authoritative information (서버가 클라이언트 요구 중 일부만 전송) |
|
204 |
No content, (PUT, POST, DELETE 요청의 경우 성공은 했지만 전송할 데이터가 없는 경우) |
|
리다이렉션 | 301 |
Moved permanently (요구한 데이터를 변경된 타 URL에 요청함 / Redirect된 경우) |
302 | Not temporarily | |
304 | Not modified (컴퓨터 로컬의 캐시 정보를 이용함, 대개 gif 등은 웹 서버에 요청하지 않음) | |
클라이언트 | 400 | Bad Request (사용자의 잘못된 요청을 처리할 수 없음) |
401 | Unauthorized (인증이 필요한 페이지를 요청한 경우) | |
402 | Payment required(예약됨) | |
403 | Forbidden (접근 금지, 디렉터리 리스팅 요청 및 관리자 페이지 접근 등을 차단) | |
404 | Not found, (요청한 페이지 없음) | |
405 | Method not allowed (혀용되지 않는 http method 사용함) | |
407 | Proxy authentication required (프락시 인증 요구됨) | |
408 | Request timeout (요청 시간 초과) | |
410 | Gone (영구적으로 사용 금지) | |
412 | Precondition failed (전체 조건 실패) | |
414 | Request-URI too long (요청 URL 길이가 긴 경우임) | |
서버에러 | 500 | Internal server error (내부 서버 오류) |
501 | Not implemented (웹 서버가 처리할 수 없음) | |
503 | Service unnailable (서비스 제공 불가) | |
504 | Gateway timeout (게이트웨이 시간 초과) | |
505 | HTTP version not supported (해당 http 버전 지원되지 않음) |
HTTP 메소드 정리
HTTP Method |
전송형태 |
설명 |
GET |
GET [request-uri]?query_string HTTP/1.1 Host:[Hostname] 혹은 [IP] |
요청받은 URI의 정보를 검색하여 응답한다. |
HEAD |
HEAD [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] |
GET방식과 동일하지만, 응답에 BODY가 없고 응답코드와 HEAD만 응답한다. 웹서버 정보확인, 헬스체크, 버젼확인, 최종 수정일자 확인등의 용도로 사용된다. |
POST |
POST [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type] [데이터] |
요청된 자원을 생성(CREATE)한다. 새로 작성된 리소스인 경우 HTTP헤더 항목 Location : URI주소를 포함하여 응답. |
PUT |
PUT [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type] [데이터] |
요청된 자원을 수정(UPDATE)한다. 내용 갱신을 위주로 Location : URI를 보내지 않아도 된다. 클라이언트측은 요청된 URI를 그대로 사용하는 것으로 간주함. |
PATCH |
PATCH [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type] [데이터] |
PUT과 유사하게 요청된 자원을 수정(UPDATE)할 때 사용한다. PUT의 경우 자원 전체를 갱신하는 의미지만, PATCH는 해당자원의 일부를 교체하는 의미로 사용. |
DELETE |
DELETE [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] |
요청된 자원을 삭제할 것을 요청함. (안전성 문제로 대부분의 서버에서 비활성) |
CONNECT |
CONNECT [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] |
동적으로 터널 모드를 교환, 프락시 기능을 요청시 사용. |
TRACE | TRACE [request-uri] HTTP/ 1.1 Host: [Hostname] 혹은 [IP] | 원격지 서버에 루프백 메시지 호출하기 위해 테스트용으로 사용. |
OPTIONS | OPTIONS [request-uri] HTTP/ 1.1 Host: [Hostname] 혹은 [IP] | 웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용. |
HTTP POST과 PUT의 차이
POST는 보통 INSERT의 개념으로 사용되고, PUT은 UPDATE개념으로 생각하면 이해하기 쉽다. 또한 POST는 멱등하지 않고 PUT은 멱등하다. 즉 동일한 자원을 여러번 POST 하면 서버자원에는 변화가 생기지만, 여러번 PUT하는 경우는 변화가 생기지 않는다.
예를들어 POST의 경우 클라이언트가 리소스의 위치를 지정하지 않는 경우 사용된다. (/dogs)
따라서, 아래와 같은 요청이 여러번 수행되는 경우 매번 새로운 dog가 생성되어 dogs/3, dogs/4 등 매번 새로운 자원이 생성된다. 멱등하지 않다는 말이다.
POST /dogs HTTP/1.1
{ "name": "blue", "age": 5 }
HTTP/1.1 201 Created
반면 PUT의 경우는 클라이언트가 명확하게 리소스의 위치를 지정한다. (/dogs/3)
따라서, 아무리 많이 수행되더라도 리소스의 위치가 지정되어 새로운 자원이 생성되지 않으며 동일한 리소스(/dogs/3)를 수정하기 때문에 여러번 요청하더라도 멱등하다.
PUT /dogs/3 HTTP/1.1
{ "name": "blue", "age": 5 }
HTTP PUT과 PATCH의 차이
PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있다. 또한 PUT의 경우는 멱등하지만, PATCH의 경우는 멱등하지 않다. PUT은 전체 자원을 업데이트 하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리된다. 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.
HTTP 멱등성
멱등(idempotent)의 의미는 같은 작업을 계속 반복해도 같은 결과가 나오는 경우를 의미한다. 동일한 자원에 대한 GET요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 한다. 특정 자원에 대한 DELETE의 경우도 자원은 더이상 이용하 수 없어야 하며, DELETE요청을 다시 호출한 경우도 자원은 여전히 사용할 수 없는 상태야여 한다.
참고 사이트
https://ko.wikipedia.org/wiki/HTTP
'JAVA > 프로그래밍 이론' 카테고리의 다른 글
| EJB CMT 방식의 2PC XADatasource처리방식 (0) | 2018.05.15 |
|---|---|
| 암호화 양방향, 단방향, 공개키(비댕칭키), 비공개키(대칭키) 개념/분류 알고리즘 정리 (1) | 2018.05.08 |
| TCP 연결부터 종료 과정 3-way Handshaking, 4-way Handshaking (0) | 2018.05.04 |
| AtomicInterger 완전정복 - CAS알고리즘(compareAndSet) (0) | 2018.05.03 |
| JAVA 접근제한자 public protected default private (0) | 2018.05.01 |
