rest api response codes
이 자습서에서는 다양한 REST 응답 코드, REST 요청 유형 및 따라야 할 몇 가지 모범 사례에 대해 알아 봅니다. :
이전 자습서 인 REST API 아키텍처 및 제약 조건에서 웹 서비스, REST 아키텍처, POSTMAN 등에 대해 배웠습니다.
이에 대한 자세한 내용은 REST API 첫 번째 자습서를 참조 할 수 있습니다.
검색 엔진에서 단어 나 구를 검색 할 때마다 검색 엔진은 요청을 웹 서버로 보냅니다. 웹 서버는 요청 상태를 나타내는 3 자리 응답 코드를 반환합니다.
학습 내용 :
Rest API 응답 코드
다음은 POSTMAN 또는 REST API 클라이언트를 통해 REST API 테스트를 수행하는 동안 일반적으로 볼 수있는 몇 가지 샘플 응답 코드입니다.
# 1) 100 시리즈
일시적인 응답입니다.
- 100 계속
- 101 스위칭 프로토콜
- 102 처리
# 2) 200 시리즈
클라이언트는 요청을 수락하고 서버에서 성공적으로 처리됩니다.
C ++ 1 초 동안 일시 중지
- 200 – 확인
- 201 – 생성됨
- 202 – 수락 됨
- 203 – 신뢰할 수없는 정보
- 204 – 내용 없음
- 205 – 콘텐츠 재설정
- 206 – 부분 콘텐츠
- 207 – 다중 상태
- 208 – 이미보고 됨
- 226 – IM 사용
# 3) 300 시리즈
이 시리즈와 관련된 대부분의 코드는 URL 리디렉션 용입니다.
- 300 – 다중 선택
- 301 – 영구 이동
- 302 – 발견
- 303 – 기타 확인
- 304 – 수정되지 않음
- 305 – 프록시 사용
- 306 – 스위치 프록시
- 307 – 임시 리디렉션
- 308 – 영구 리디렉션
# 4) 400 시리즈
이는 클라이언트 측 오류에만 해당됩니다.
- 400 잘못된 요청
- 401 – 승인되지 않음
- 402 – 결제 필요
- 403 금지
- 404 찾을 수 없음
- 405 – 허용되지 않는 방법
- 406 – 허용되지 않음
- 407 – 프록시 인증 필요
- 408 – 요청 시간 초과
- 409 – 충돌
- 410 – 사라짐
- 411 – 필요한 길이
- 412 – 전제 조건 실패
- 413 – 페이로드가 너무 큼
- 414 – URI가 너무 김
- 415 – 지원되지 않는 미디어 유형
- 416 – 범위가 만족스럽지 않음
- 417 – 예상 실패
- 418 – 나는 주전자입니다
- 421 – 잘못된 요청
- 422 – 처리 할 수없는 엔티티
- 423 – 잠김
- 424 – 실패한 종속성
- 426 – 업그레이드 필요
- 428 – 전제 조건 필요
- 429 – 너무 많은 요청
- 431 – 요청 헤더 필드가 너무 큼
- 451 – 법적 이유로 사용할 수 없음
# 5) 500 시리즈
이는 서버 측 오류와 관련이 있습니다.
- 500 내부 서버 오류
- 501 – 구현되지 않음
- 502 – 잘못된 게이트웨이
- 503 – 서비스를 사용할 수 없음
- 504 게이트웨이 시간 초과
- 505 – HTTP 버전이 지원되지 않음
- 506 – 변형도 협상
- 507 – 저장 공간 부족
- 508 – 루프 감지 됨
- 510 – 확장되지 않음
- 511 – 네트워크 인증 필요
이 외에도 여러 가지 코드가 존재하지만 현재 논의에서 벗어나게 될 것입니다.
다양한 유형의 REST 요청
여기서는 컬렉션과 함께 REST API의 모든 방법에 대해 설명합니다.
| 방법 | 기술 |
|---|---|
| 반점 | put과 매우 유사하지만 리소스 콘텐츠의 사소한 조작에 더 가깝습니다. |
| 가져 오기 | 상태 표시 줄, 응답 본문, 헤더 등을 가져옵니다. |
| 머리 | GET과 동일하지만 상태 줄 및 헤더 섹션 만 가져옵니다. |
| 게시하다 | 서버에서 레코드를 생성 할 때 주로 요청 페이로드를 사용하여 요청 수행 |
| 놓다 | 요청 페이로드를 사용하여 리소스를 조작 / 업데이트하는 데 유용합니다. |
| 지우다 | 대상 리소스와 관련된 정보를 삭제합니다. |
| 옵션 | 대상 자원에 대한 통신 옵션 설명 |
노트 : POSTMAN을 사용하여 할 수있는 방법이 너무나 많이 존재하지만 POSTMAN을 사용하여 다음 방법 만 논의 할 것입니다.
가상 URL을 사용하여 http://jsonplaceholder.typicode.com . 이 URL은 원하는 응답을 제공하지만 서버에서 생성, 수정은 없습니다.
# 1) GET
요청 매개 변수 :
방법 : GET
요청 URI : http://jsonplaceholder.typicode.com/posts
검색어 매개 변수 : id = 3;
수신 된 응답 :
응답 상태 코드 : 200 OK
응답 본문 :
# 2) 머리
요청 매개 변수 :
방법 : HEAD
요청 URI : http://jsonplaceholder.typicode.com/posts
# 3) POST
# 4) PUT
# 5) 옵션
요청 매개 변수 :
방법 : 옵션
요청 URI : http://jsonplaceholder.typicode.com/
헤더 : 콘텐츠 유형 = 애플리케이션 / JSON
# 6) 패치
REST API를 검증하는 동안 모범 사례
# 1) CRUD 작업
제공된 최소 4 개의 메소드로 구성되며 웹 API에서 작동해야합니다.
GET, POST, PUT 및 DELETE.
# 2) 오류 처리
오픈 소스 웹 서비스 테스트 도구
API 소비자에게 오류 및 오류 발생 이유에 대한 가능한 힌트입니다. 또한 세분화 된 수준의 오류 메시지를 제공해야합니다.
# 3) API 버전 관리
URL에 문자 'v'를 사용하여 API 버전을 나타냅니다. 예를 들면
http://restapi.com/api/v3/passed/319
URL 끝에 추가 매개 변수
http://restapi.com/api/user/invaiiduser?v=6.0
# 4) 필터링
사용자가 지정할 수 있도록 한 번에 모두 제공하는 대신 원하는 데이터를 선택하십시오.
/ contact / sam? 이름, 나이, 명칭, 사무실
/ contacts? limit = 25 & offset = 20
# 5) 보안
각각의 모든 API 요청 및 응답의 타임 스탬프. API가 신뢰 당사자에 의해 호출되는지 확인하기 위해 access_token을 사용합니다.
초보자를위한 프로그래머가되는 방법
# 6) 분석
REST API에 Analytics가 있으면 특히 가져온 레코드 수가 매우 많은 경우 테스트중인 API에 대한 좋은 통찰력을 얻을 수 있습니다.
# 7) 문서
API 소비자가이를 사용하고 서비스를 효과적으로 사용할 수 있도록 적절한 문서를 제공해야합니다.
# 8) URL 구조
URL 구조는 단순해야하며 사용자는 도메인 이름을 쉽게 읽을 수 있어야합니다.
예를 들어 , https://api.testdomain.com.
Rest API를 통해 수행 할 작업도 이해하고 수행하기가 매우 쉬워야합니다.
예를 들어 이메일 클라이언트의 경우 :
가져 오기: 읽기 /받은 편지함 / 메시지 –받은 편지함의 모든 메시지 목록을 검색합니다.
가져 오기: 읽기 /받은 편지함 / 메시지 / 10 – 읽기 10일받은 편지함의 메시지
게시하다: 생성 /받은 편지함 / 폴더 –받은 편지함 아래에 새 폴더 생성
지우다: 삭제 / 스팸 / 메시지 – 스팸 폴더에있는 모든 메시지 삭제
놓다: 폴더 /받은 편지함 / 하위 폴더 –받은 편지함 아래의 하위 폴더와 관련된 정보를 업데이트합니다.
결론
많은 조직에서 REST Web API를 구현하는 것을 선호합니다. REST 웹 API는 구현하기가 매우 쉽고, 따라야 할 표준과 규칙이 적고, 액세스하기 쉽고, 가볍고, 이해하기 쉽기 때문입니다. POSTMAN은 사용자 친화적 인 UI, 사용 및 테스트의 용이성, 빠른 응답률 및 새로운 RUNNER 기능으로 인해 RESTful API와 함께 사용할 때 장점이 있습니다.
이 Rest API 튜토리얼 시리즈의 다음 튜토리얼에서는 수동으로 실행 한 테스트 케이스를 자동화 할 것입니다.