일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- programmers
- Git
- 제약 조건
- 페이지네이션
- git reflog
- Late row lookup
- kafka-connect
- debezium
- Pagination Optimization
- Query String
- code --no-sandbox
- kafkaconnect
- 1450
- foreign key constraint fails
- kafka connect
- reflog
- git rebase -i
- API 설계
- 참조무결성
- 문자열 검증
- Path Variable
- Cannot delete or update a parent row: a foreign key constraint fails
- jdbc connector
- Invalid character found in method name
- 23000
- event loop
- constraint fails
- 페이지네이션 최적화
- Cannot add or update a child row: a foreign key constraint fails
- 1452
- Today
- Total
Kawaii_Jordy
[REST API] HTTP status code (HTTP 상태 코드) 본문
HTTP 상태 코드 또는 응답 코드는 5가지 범주로 나뉘다.
1× 정보, 2× 성공, 3× 리디렉션, 4× 클라이언트 오류, 5× 서버 오류. (자세한 내용은 아래 표 참조)
우리가 API 테스트를 할 때, 보통 API 호출의 응답을 가장 먼저 확인하는 것이 바로 HTTP Status Code 이다 (HTTP 상태 코드)
HTTP 와 REST
HTTP(HyperText Transfer Protocol)는 웹 환경에서 정보를 주고받기 위한 프로토콜이다.
HTTP
- 클라이언트는 HTTP의 상태 코드를 확인하여 요청의 성공|실패를 확인할 수 있다.
- 이것은 HTTP를 사용하는 클라이언트와 서버 간의 약속, 프로토콜인 것이다.
REST(Representational State Transfer)는 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처이다.
REST
HTTP는 웹 환경에서 정보를 송수신할 때 사용하는 약속이고, REST는 소프트웨어 아키텍처다.
REST에 반드시 HTTP가 필요한 것은 아니다. WAP, WebRTC, MQTT 등 다른 프로토콜로도 이용 가능하다.
REST는 소프트웨어 아키텍처(설계 지침, 원리 등등)고 REST에서 클라이언트-서버 간 통신 시 HTTP를 사용한 것이다.
그래서 REST에서 HTTP는?
REST에서 HTTP는 필수가 아니라고 했지만, 웹 환경 통신의 대부분이 HTTP를 사용한다.
만약, 어떤 API의 요청|응답 데이터 포맷이 YAML이면 어떨까?
물론 YAML이 JSON 포맷의 데이터를 대체하여 표현할 수 있고 JSON이 갖는 한계를 보완한 부분도 있지만, 일반적이지 않다.
일반적이지 않은 것은 불편함을 야기한다. 이러한 불편함을 감수하면서 일반적이지 않는 것을 사용하려면 매우 설득력 있는 근거가 필요하다.
REST의 경우엔 현재로선 없다.
REST는 HTTP를 사용하는 것이 일반적이다. 필수가 아니라고 했지만, 거의 필수다.
REST의 개념/원리에는 HTTP가 필수는 아니지만, 그 사용에 있어 필수적으로 변한 경우라 생각하면 좋을 거 같다. (de-facto standard)
누군가 만든 REST API가 HTTP를 사용하지 않는다면 이것부터 고치라고 지시할 것이다.
따라서 REST를 이용해 API를 설계하려면 HTTP에 대해서 알고 있어야 한다.
https://www.yevgnenll.me/posts/401-vs-403
Status Code |
결과 | 설명 | |
정보 (Information) |
100 | Continue | 요청 메시지의 첫부분이 서버에 도착했고, 클라이언트는 계속 요청 가능 |
101 | Swtiching | 서버는 Upgrade 헤더에 정의된 프로토콜을 변환하기 위해 클라이언트 요청수락 | |
성공 (Success) |
200 | OK | 요청 성공 |
201 | Created | 새로운 URL 생성 | |
202 | Accepted | 요청 수락, 바로 실행되지는 않음 | |
204 | No Content | 헤더의 바디 부분에 데이터가 없음 | |
재지정 (Redirection) |
300 | Multiple Choices |
요청된 URL 이 여러 개 |
301 | Move permanently |
요청된 URL 이 존재 않음 | |
302 | Move temporaily |
요청된 URL 으로 이동 | |
304 | Not Modified | 문서가 수정되지 않음 | |
클라이언트 오류 (Client Error) |
400 | Bad Request | 요청 메시지의 문법 오류 |
401 | Unauthorized | 요청 페이지 내 클라이언트 인증 오류 | |
403 | Forbidden | 서비스 거부 ( 방화벽에서 IP, Port 가 막혔을 경우, 라우팅이 잘못된 되었을 경우) | |
404 | Not Found | 요청한 페이지가 없음 | |
405 | Method not allowed |
메소드를 지원하지 않음 | |
406 | Not Acceptable | 요청한 형식 거부 | |
서버 오류 (Server Error) |
500 | Internal Server Error | 메시지 손상과 같은 오류 발생 |
501 | Not implemented | 요청된 메소드를 수행 불 가능 | |
503 | Service Unavailable | 잠시 동안 서비스 사용 불가능 |
'취준 > API 설계' 카테고리의 다른 글
[Type Guard] type에 대한 확실한 정의가 필요 (0) | 2021.05.31 |
---|---|
[Rest API] HTTP Status Code 401, 403 비교 분석 (0) | 2021.05.17 |