서버 응답 및 데이터 유형

서버에서 오는 Response는 Request와 거의 동일한 방식으로 작동합니다. 명백한 이유로 요청 매개변수가 없지만 헤더와 본문이 응답에 포함됩니다(비어 있을 수 있음).

중요한 차이점은 응답 상태입니다.

상태 코드

상태 코드 . 서버 응답의 첫 번째 줄에 있습니다. 상태는 3자리 숫자(코드 자체)이며, 그 뒤에 이를 설명하는 문구가 있습니다.

요청 결과에 대해 알아내고 다음에 취해야 할 조치를 이해할 수 있는 것은 상태 코드입니다.

가능한 모든 상태 코드는 5개의 클래스로 나뉩니다. 코드의 첫 번째 숫자는 특정 클래스에 속하는 것을 결정합니다. 그것들을 분해해 봅시다.

1xx — 정보 코드. 요청 진행 상황을 보고합니다. 실제로는 거의 사용되지 않습니다.

2xx — 성공 코드. 그들은 모든 것이 정상이고 요청이 성공적으로 완료되었다고 보고합니다. GET 요청에 대한 응답으로 일반적으로 200(OK) 코드를 수신할 것으로 예상합니다. 성공적인 PUT 요청은 201(Created) 코드를 보냅니다.

3xx — 리디렉션합니다. 요청을 다른 주소로 보내야 함을 나타냅니다. 예는 코드 301(영구적으로 이동됨)으로, 필요한 데이터가 이제 새 주소에 있음을 나타냅니다(새 주소 자체가 Location 헤더에 전달됨).

4xx — 클라이언트 오류 코드. 그 중 가장 유명한 404(찾을 수 없음)는 지정된 주소에 필요한 데이터가 없다고 보고합니다. 기타 일반적인 경우: 400(잘못된 요청, 요청의 구문 오류), 401(무단, 액세스에 인증 필요), 403(금지, 액세스 거부).

5xx — 서버 오류 코드. 서버 측에서 오류를 보고합니다. 예: 500(내부 서버 오류, 알려진 코드로 인한 이해할 수 없는 모든 오류), 503(서비스 이용 불가, 서버가 일시적으로 기술적인 이유로 요청을 처리할 수 없음)

데이터 유형

이 시점에서 REST API와 HTTP 요청 및 응답의 구조를 이해하기 위한 기본 정보를 다뤘다고 가정할 수 있습니다. 데이터 유형이라는 한 가지 요점만 명확히 해야 합니다. 이미 AppMaster에서 API 요청을 생성하려고 시도했다면 모든 데이터(매개변수, 헤더, 본문)가 이름뿐만 아니라 데이터 유형도 지정하도록 요청한다는 것을 눈치챘을 것입니다.

특정 컨텍스트가 있기 때문에 데이터로 작업하는 방법은 일반적으로 사람에게 매우 분명합니다. 2 + 2 = 4라는 것을 알고 있다고 가정합니다. 우리는 이것이 숫자이고 덧셈의 결과가 다른 숫자가 될 것이라고 추측합니다.

그러나 숫자가 아니라 텍스트 데이터일 수 있습니다. 그런 다음 추가 결과는 문자열의 연결이 될 수 있으며 2 + 2는 "22"로 바뀝니다. 여기에 컴퓨터가 아무 것도 생각할 필요가 없도록 데이터 유형에 대한 정확한 표시가 있습니다. 동시에 다른 작업도 해결되고 있습니다. 예를 들어 잘못된 데이터 입력에 대한 보호가 제공됩니다. 처음에는 전화번호 입력란에 이메일 주소를 등록할 기회가 없습니다.

다양한 데이터 유형이 있습니다. 이제 가장 기본적인 데이터 유형을 고려하고 과정의 추가 모듈에서 나머지에 대해 알게 될 것입니다.

문자열 — 문자열 데이터 유형, 특별한 형식이 없는 일반 텍스트입니다.

정수 — 정수 데이터 유형입니다. 분수가 필요하지 않은 카운터 또는 계산에 사용할 수 있습니다.

부동 소수점 — 부동 소수점 숫자입니다. 증가된 정밀도가 필요하고 정수 값이 충분하지 않은 경우에 사용됩니다.

여기서 논리적인 질문이 제기될 수 있습니다. 그리고 항상 Float를 사용하지 않는 이유는 무엇입니까? 그렇다면 Integer가 필요한 이유는 무엇입니까? 그러나 정확도를 높이려면 더 많은 리소스가 필요합니다. 일부 작은 계산에서는 이것이 완전히 보이지 않을 수 있지만 데이터 양이 많은 경우 합리적인 데이터 유형을 사용하면 컴퓨팅 성능 및 디스크 공간에 대한 요구 사항을 크게 줄일 수 있습니다.

부울 — 부울 데이터 유형입니다. 가장 단순한 데이터 유형. True 또는 False 로 작성된 두 값 중 하나를 사용합니다. 1(true)과 0(false)의 형태로 명칭을 흔히 볼 수 있다.