URI, URL
URI
는 Locator, Name 또는 둘다 추가로 분류될 수 있다.
URI
: Uniform(리소스를 식별하는 통일된 방식) Resource(자원) Identifier(식별자)
- URL: Locator (위치)
- URN: Name
HTTP 상태코드
- client가 server로의 요청 처리 상태를 응답해서 알려줌
- 클라이언트가 모르는 상태코드가 나타나면, 클라이언트는 상위 상태코드로 해석 처리
- 399?.. 399는 모르겠고, 3--이니 뭔가 추가행동이 필요하겠군!
상태 코드 | 설명 |
---|
1xx (informal) | 요청이 수신되어 처리중 |
2xx (Successful) | 요청 정상 처리 |
3xx (Redirection) | 요청을 완료하려면, 추가 행동이 필요 |
4xx (Client Error) | 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 |
5xx (Server Error) | 서버 오류, 서버가 정상 요청을 처리하지 못함 |
2xx : 성공
클라이언트의 요청을 성공적 처리
상태 코드 | 설명 | 추가 설명 |
---|
200 | OK | 처리 완료 |
201 | Created | 클라이언트가 요청한 것을 서버에서 무언가를 생성했다. |
202 | Accepted | 요청이 접수되었으나 처리가 완료되지 않았음 |
204 | No Content | 서버가 요청을 성공적으로 수행했으나, 응답 페이로드 본문에 보낼 데이터가 없음웹 문서 편집기에서 save버튼 클릭save 버튼의 결과로 아무 내용이 없어도 된다.save 버튼을 눌러도 같은 화면을 유지해야 한다.결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다. |
200 OK
GET /members/100 HTTP/1.1
Host: localhost:8080
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34
{
"username": "yang",
"age": 20
}
201 Created
- 요청 성공해서 새로운 리소스가 생성됨
- 클라이언트: 요청
POST /members HTTP/1.1
Content-Type: application/json
{
"username": "yang",
"age": 20
}
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 # 생성된 리소스는 응답의 Location 헤더 필드로 식별
{
"username": "yang",
"age": 20
}
- 201을 받았으면, 클라이언트는 서버에서 무엇을 생성했구나!, Location 헤더가 있겠구나!
202 Accepted
- 요청이 접수되었으나 처리가 완료되지 않았음
- 클라이언트: 요청
POST /members HTTP/1.1
Content-Type: application/json
{
"username": "yang",
"age": 20
}
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 # 생성된 리소스는 응답의 Location 헤더 필드로 식별
{
"username": "yang",
"age": 20
}
3xx : Redirection
- 웹브라우저는 3xx 응답에, Location 헤더가 오면, 자동적으로 Redirect한다.
상태 코드 | 설명 | 추가 설명 |
---|
300 | Multiple Choices | 잘 사용되지 않음 |
301 | Moved Permanently | 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 |
302 | Found | 일시적인 리다이렉션: 리소스의 URI가 일시적으로 변경리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음자세한 설명은 일시적인 리다이렉션 참고302 스펙의 의도는 HTTP 메서드를 유지하는 것그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림그래서 모호한 302를 대신하는 명확한 307, 303등이 등장함메서드가 GET으로 변할 수 있음 |
303 | See Other | 일시적인 리다이렉션: 302와 기능은 같음리다이렉트시 요청메서드가 GET으로 변경메서드가 GET으로 변경 |
304 | Not Modified | 캐시를 목적으로 사용클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서, 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. 즉, 클라이언트는 캐시로 리다이렉트304 응답은 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용해야 하므로)조건부 GET, HEAD요청 시 사용 |
307 | Temporary Redirect | 일시 리다이렉션: 302와 기능은 같음리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다 |
308 | Permanent Redirect | 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동301과 기능은 같음리다이렉트시 요청 메서드와 본문 유지 |
301: Moved Permanently
- 클라이언트: 요청
POST /event HTTP/1.1
Host: localhost:8080
name=hello&age=20 # <- 메시지 존재
- 서버: 응답
HTTP/1.1 301 Moved Permanently
Location: /new-event
- 클라이언트: 요청, 자동 리다이렉트
GET /new-event HTTP/1.1 # <- GET으로 변경되고, URL이 /new-event로 리다이렉트
Host: localhost:8080
# <- 원래 메시지가 사라짐. 즉, /new-event 화면만 보여질 것임
- 서버: 응답
HTTP/1.1 200 OK
...
308: Permanent Redirect
- 클라이언트: 요청
POST /event HTTP/1.1
Host: localhost:8080
name=hello&age=20 # <- 메시지 존재
- 서버: 응답
HTTP/1.1 308 Permanent Redirect
Location: /new-event
- 클라이언트: 요청, 자동 리다이렉트
POST /new-event HTTP/1.1 # <- POST로 유지. URL이 /new-event로 리다이렉트
Host: localhost:8080
name=hello&age=20 # <- 원래 메시지 유지
- 서버: 응답
HTTP/1.1 200 OK
...
일시적 리다이렉션의 예
- PRG: Post/Redirect/Get
- POST로 주문 후에 웹 브라우저를 새로고침하면?
- 새로고침은 다시 요청
- 중복 주문 가능성
- 클라이언트: 요청
POST /order HTTP/1.1 # <- POST 사용
Host: localhost:8080
itemId=mouse&count=1
- 서버: 주문데이터 저장
2.1. DB에 mouse 1개 등록
- 서버: 응답
HTTP/1.1 200 OK
<html>주문완료</html>
- 여기서 사용자가 새로 고침을 할 경우!!
클라이언트: 요청
POST /order HTTP/1.1 # <- 또 POST사용!!!!
Host: localhost:8080
itemID=mouse&count=1
- 서버: 다시 주문데이터 저장
5.1. DB에 mouse 1개 등록
- 서버: 응답
HTTP/1.1 200 OK
<html>주문완료</html>
- 결국 새로고침 때문에, 클라이언트는 2번 요청한다. (너무 당연하겠지만..)
- 이 문제를 해결하기 위해 POST 주문 후에, 결과화면을 GET메서드로 리다이렉트
- 새로고침해도 결과 화면을 GET으로 조회
- 클라이언트: 요청
POST /order HTTP/1.1 # <- POST 사용
Host: localhost:8080
itemId=mouse&count=1
- 서버: 주문데이터 저장
2.1. DB에 mouse 1개 등록
- 서버: 응답
HTTP/1.1 302 Found # <- 200 OK가 아니고 302 Found 및
Location: /order-result/19 # <- Location 보냄
- 이럴 경우 사용자 클라이언트는 302 Found를 응답받았으므로, Location를 찾을 것이고
거기로 임시 Redirect한다.
GET /order-result/19 # <- GET으로 위 서버의 응답의 Location으로 요청
Host: localhost:8080
itemID=mouse&count=1
- 서버: 다시 주문데이터 저장
5.1. DB에 mouse 1개 등록
- 서버: 응답
HTTP/1.1 200 OK
<html>주문완료</html>
4xx : 클라이언트 오류
- 오류의 원인이 클라이언트에 있음: 4xx대
- 클라이언트 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 클라이언트가 이미 잘못된 요청을 하기 때문에, 똑같은 재시도가 실패 할 것
상태 코드 | 설명 | 추가 설명 |
---|
400 | Bad Request | 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음요청 구문, 메시지 등등 오류클라이언트는 요청 내용을 다시 검토하고, 보내야함예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 |
401 | Unauthorized | 클라이언트가 해당 리소스에 대한 인증이 필요함: 인증(Authentication) 되지 않음401 오류 발생 시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명 참고- 인증(Authentication): 본인이 누구인지 확인(로그인)
- 인가(Authorization): 권한 부여(admin 권한처럼, 특정 리소스에 접근할 수 있는 권한
인증이 있어야 인가가 있음) - 오류 메시지가 Unauthorized 이지만 인증 되지 않음(이름이 아쉬움)
|
403 | Forbidden | 서버가 요청을 이해했지만, 승인을 거부함요청 리소스가 서버에 없음클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때즉, 서버가 클라이언트한테 리소스를 보여주고 싶지 않을 때 |
404 | Not Found | 요청 리소스를 찾을 수 없음요청 리소스가 서버에 없음또는 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때 |
5xx : 서버 오류
- 오류의 원인이 서버에 있음: 5xx대
- 서버 문제로 오류 발생
- 서버에 문제가 있기 때문에, 재시도하면 성공할 수도 있음
상태 코드 | 설명 | 추가 설명 |
---|
500 | Internal Server Error | 서버 문제로 오류 발생 |
503 | Service Unabailable | 서비스 이용 불가서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있음 |
html
출처:https://aboooks.tistory.com/210