첫 번째 모듈은 HTTP 요청을 생성하고 전송하고 응답을 받는 것으로 끝났습니다.

우리는 앞으로 이것을 더 많이 할 것입니다. 우리는 제3자 서버에 요청을 보낼 것입니다. 우리는 스스로 그러한 요청을 수락하고 응답을 반환하는 응용 프로그램을 만들 것입니다. 우리는 요청을 처리하기 위한 복잡한 논리를 만들 것입니다.

따라서 이러한 요청과 관련된 모든 것을 철저히 연구하여 자세히 분석하는 것이 좋습니다. 요청을 어딘가에 복사하고 반복할 수는 없지만 모든 것이 어떻게 작동하는지 실제로 알아낼 수 있습니다.

이것이 우리가 두 번째 모듈에서 할 일입니다. 갑시다!

이론부터 시작하겠습니다.


REST API 학습

REST API 기본 사항

첫 번째 모듈에서 숙제를 하고 문서를 공부했다면 약어 API를 눈치채셨을 것입니다. 실제로 개발자가 네트워크의 일부 서비스 또는 응용 프로그램과의 상호 작용을 이해하려는 경우 가장 먼저 연구해야 하는 것은 API 문서입니다.

API - 애플리케이션 프로그래밍 인터페이스. 이것은 클라이언트와 서버가 서로 통신할 수 있는 방법에 대한 설명입니다. API 문서를 열고 서버에서 필요한 데이터를 가져오는 방법을 배웁니다.

우리는 항상 이 상호작용이 간단하고 이해하기를 원합니다. 이것은 개발자(새로운 서비스를 디자인할 때 바퀴를 재발명할 필요가 없음)와 사용자(이전에 친숙한 서비스와 동일한 원리로 작동하는 서비스가 훨씬 더 배우기 쉽습니다) 모두의 작업을 단순화합니다. 그리고 여기서 REST라는 새로운 용어를 기억할 가치가 있습니다.

REST - Representational State Transfer 의 약어. 명확하게 들리지 않을 수 있지만 간단히 말해서 REST는 클라이언트와 서버 간의 상호 작용(정보 교환) 스타일입니다.

이것은 엄격한 규칙 및 요구 사항 집합이 아닙니다. REST는 특정 프로그래밍 언어의 사용을 강요하지 않으며 엄격한 지침으로 손을 묶지 않습니다. REST는 아키텍처 스타일이라고 하며 시스템 아키텍처가 준수해야 하는 6가지 원칙을 정의합니다.

따라서 REST의 원리를 고려하여 개발된 API를 REST API 라고 하며, 애플리케이션 자체를 RESTful 이라고 합니다.

우리는 바로 그러한 RESTful 애플리케이션을 만들 것이므로 그들이 즉시 준수할 원칙에 대해 논의할 가치가 있습니다.

  1. 클라이언트-서버 모델. 원칙은 클라이언트와 서버의 분리, 요구 사항의 차별화를 정의합니다. 클라이언트는 데이터가 저장되는 방식에 대해 걱정할 필요가 없습니다. 중요한 것은 요청 시 데이터가 발행된다는 것입니다. 결과적으로 서버는 클라이언트가 이 데이터로 무엇을 할지, 어떻게 처리하고 표시할지 신경 쓰지 않습니다. 이를 통해 서로 독립적으로 개발할 수 있으며 시스템의 확장성이 향상됩니다.
  2. 무국적자. 이 원칙은 서버가 이 클라이언트에 대한 이전 경험을 기반으로 응답을 "생각"해서는 안 된다는 것을 의미합니다. 모든 요청은 이전 요청에 관계없이 처리에 필요한 모든 정보를 포함하는 방식으로 이루어집니다.
  3. 캐싱. 전송되는 데이터를 최소화하기 위해 캐싱 메커니즘이 있습니다. 예를 들어 어떤 페이지에 로고가 표시되면 매번 서버에 로고를 요청하는 것은 의미가 없습니다. 너무 자주 변경되지 않으므로 한 번 가져 와서 클라이언트 컴퓨터의 캐시에 저장하면 충분합니다. 그러나 자동차의 현재 속도에 대한 정보를 얻어야 한다면 캐시는 어떤 식으로든 도움이 되지 않습니다. 이 원칙은 서버에서 전송하는 데이터를 캐시 가능으로 지정해야 하는지 여부를 결정합니다.
  4. 균일한 인터페이스. 이 원칙은 클라이언트-서버 상호 작용의 단일 형식을 정의합니다. 모든 요청의 구조는 동일해야 합니다. 데이터를 요청하는 사람에 관계없이 동일한 형식으로 데이터를 보내야 합니다.
  5. 계층화된 시스템. 클라이언트와 서버가 반드시 직접 통신하는 것은 아닙니다. 데이터 전송은 여러 중간 노드를 통과할 수 있습니다. 이 경우 시스템은 클라이언트도 서버도 최종 응용 프로그램과 상호 작용하는지 아니면 중간 노드와 상호 작용하는지 알 수 없도록 설계되었습니다. 이를 통해 서버의 로드 균형을 조정하고 확장성을 높일 수 있습니다.
  6. 주문형 코드 (선택 사항) . 필수가 아닌 유일한 원칙. 이에 따르면 클라이언트는 서버에서 실행 코드(예: 스크립트)를 다운로드하여 기능을 확장할 수 있습니다. 이 경우 코드는 요청 시에만 실행되어야 합니다.

이론이 너무 많지 않습니까?

이것을 실천해 봅시다.

API 요청 생성

AppMaster 를 열고 이를 사용하여 API 요청을 만들고 이 요청이 어떻게 작동하는지 더 잘 이해해 보겠습니다.


API 요청은 "외부 API 요청" 탭의 "비즈니스 로직" 섹션에서 생성됩니다.

"+ 새 API 요청"을 클릭할 차례입니다.


이름과 설명은 무엇이든 설정할 수 있으며 개인적인 용도로만 사용할 수 있습니다.

정말 중요한 데이터를 다루겠습니다.

요청을 생성하는 데 필요한 최소 요구 사항은 해당 메서드 및 주소(URL)를 지정하는 것입니다. 마지막으로 시작하겠습니다.


URL - Uniform Resource Locator. 인터넷의 특정 리소스에 지정된 주소입니다. 이러한 리소스의 가장 친숙한 버전은 HTML 페이지입니다. 브라우저의 주소 표시줄에 해당 URL을 입력하고 원하는 사이트를 엽니다. 동시에 리소스 자체는 사진, 비디오, 데이터 세트 등 무엇이든 될 수 있습니다. 중요한 것은 이 리소스에 특정 포인터(이 리소스를 가져오기 위해 요청을 보낼 수 있는 URL)가 있다는 것입니다.

해당 주소의 데이터를 참조하여 요청의 방법(유형을 말할 수도 있음)도 나타냅니다. 즉, 이 데이터로 실제로 수행해야 하는 작업을 나타냅니다.

첫 번째 모듈의 작업에 대한 요청을 보냈을 때 데이터를 받았습니다. 이것이 GET 방식입니다. 이 방법은 가장 확실한 방법이자 유일하게 필요한 방법입니다. 따라서 명시적으로 지정하지 않더라도 기본적으로 GET인 것으로 가정합니다.

다른 방법이 있는지 봅시다.


HTTP 표준 자체는 사용할 수 있는 메서드의 수를 제한하지 않습니다. 동시에 가장 표준적인 방법 중 일부만 호환성을 유지하는 데 여전히 사용됩니다. AppMaster API 요청에서 사용할 수 있는 5가지 방법이 있습니다.

  • GET . 이미 처리되었습니다. 메소드는 리소스 제공을 요청하고 데이터를 수신합니다.
  • 포스트 . 어딘가에서 데이터를 가져오려면 먼저 이 데이터를 거기에 배치해야 합니다. POST 메서드는 바로 그 작업을 수행합니다. 서버에 데이터를 보내고 리소스를 만듭니다.
  • 넣어 . POST 방법과 유사하지만 그 작업은 데이터를 업데이트하는 것입니다. 새로운 데이터를 생성하지 않고 기존 데이터를 교체하고 업데이트합니다.
  • 삭제 . 이름에서 알 수 있듯이 데이터를 삭제합니다.
  • 패치 . 이 방법은 PUT과 유사하지만 데이터를 완전히 교체하는 대신 부분적으로 데이터를 업데이트하는 데 사용됩니다. 예를 들어, PATCH 방법을 사용하여 기사 제목을 변경하거나 일부 매개변수의 값을 변경할 수 있습니다.

서버가 메서드에 지정된 작업을 전혀 수행할 필요가 없다는 사실을 고려하는 것이 중요합니다. DELETE 메소드를 사용하여 일부 페이지의 주소를 보낼 수 있지만 이것이 서버가 실제로 삭제한다는 의미는 아닙니다. 그러나 순전히 이론적으로는 GET 명령으로 이를 수행할 수 있습니다. 또는 아무 것도 변경하지 않고 동시에 POST에 대한 응답으로 데이터를 보냅니다. 개발자가 그렇게 구성했기 때문입니다.

이것은 REST가 작동하는 곳입니다. 명령 준수에 동의하고 혼란을 멈추고 메서드에 표시된 대로 정확하게 수행해야 할 때입니다. 최소한 이것이 주요 작업이어야 합니다(단 하나는 아닐지라도). 예를 들어 GET 방법을 사용하여 기사의 내용을 전송할 때 동시에 조회수 카운터를 1 늘릴 수 있습니다.

그래서 우리는 데이터가 어디에 있고 무엇을 할 수 있는지 알아냈습니다. 더 나아가 요청에 포함할 수 있는 다른 구성 요소를 살펴보겠습니다.


URL 매개변수. URL의 일부만 아는 상황이 있습니다. Appmaster.io 웹사이트의 기사가 그 예입니다. 모든 기사의 시작 주소는 동일합니다 - https://appmaster.io/en/blog/. 그러나 각 기사에는 고유한 제목이 있으므로 이 특정 기사의 정확한 표시를 위한 고유한 개별 부분이 있습니다.

이러한 상황에서 URL 매개변수가 사용됩니다. 일반적인 부분은 즉시 처방하고 나머지는 그 과정에서 결정하도록 합니다. 결과적으로 URL은 https://appmaster.io/ru/blog/:id/ 형식으로 작성됩니다.

알려진 부분은 있는 그대로 쓰고 변수 부분은 ":" 기호 뒤에 위치합니다. 이 변수 부분의 이름(이미 ":" 없음)이 매개변수 목록에 추가됩니다. 이 경우 여러 변수 부분이 있을 수 있으며 해당 위치는 URL의 아무 곳에나 있습니다.


쿼리 매개변수 . 첫 번째 모듈에서 boreapi.com에 요청을 보냈을 때를 기억하십니까? 그리고 주소 외에도 추가 데이터가 처방되었습니다. 쿼리 매개변수였습니다.

URL 뒤에 쓰여지고 "?"로 구분됩니다. 징후. 매개변수의 이름, "=" 기호 및 매개변수 자체의 값이 표시됩니다. 한 번에 여러 매개변수를 사용하는 경우 "&" 기호로 구분합니다.

그러나 AppMaster에서 매개변수를 지정할 때 요청 규칙에 대해 생각할 필요가 없습니다. 모든 것이 자동으로 올바르게 포맷됩니다. 매개변수 자체의 이름을 지정하고 목록에 추가하기만 하면 됩니다.

Query Params는 데이터 소스는 동일하지만 데이터 자체는 다를 수 있는 경우에 사용됩니다. 예를 들어, Boredapi에는 해야 할 일의 거대한 목록이 포함되어 있습니다. 그러나 우리는 한 사람을 위한 것에만 관심이 있었고 그것이 우리가 요청 매개변수에 표시한 것입니다.

또 다른 옵션은 액세스 키입니다. Alphavantage를 언급할 때 모듈 1에서 이 옵션을 사용했을 수 있습니다. 데이터는 등록 후 요청 매개변수에 개인 키를 전송한 후에만 얻을 수 있습니다.

인터넷에서 방문하는 페이지에주의를 기울이면 다양한 매개 변수도 찾을 수 있습니다. 예를 들어 Ventusky.com의 날씨 페이지를 열면 쿼리 매개변수에서 위도와 경도의 지리적 값이 전송됩니다.

헤더 . 헤더를 요청합니다. 일반적으로 헤더에는 요청에 대한 서비스 정보(메타 정보)가 포함됩니다. 헤더를 통해 서버는 데이터를 요청하는 클라이언트에 대한 추가 정보를 얻을 수 있습니다. 헤더에는 사용 중인 브라우저, 응답이 예상되는 인코딩, 언어, 요청의 정확한 시간 등에 대한 정보가 포함될 수 있습니다. 보호된 데이터에 액세스하는 경우 헤더에 인증 키가 포함될 수 있습니다.

대부분의 경우 헤더는 선택 사항입니다. 첫 번째 모듈에서도 헤더를 지정하지 않은 요청을 이미 했습니다(이것이 실제로 요청이 헤더 없이 전송되었다는 의미는 아닙니다).

. 요청 본문. GET 요청은 일반적으로 없이 수행되지만 일부 데이터를 서버에 보내고 POST 또는 PUT 요청을 보내면 이 데이터가 요청 본문에 배치됩니다. 동시에 비디오 파일을 보내는 것과 같이 요청 본문에 복잡한 데이터를 배치할 수 있으며 일부 숫자 또는 텍스트 문자열에 제한되지 않습니다.

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

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

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

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

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

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

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

3xx — 리디렉션합니다. 요청을 다른 주소로 보내야 함을 나타냅니다. 예는 코드 301(Moved Permanently)이며 필요한 데이터가 이제 새 주소에 있음을 나타냅니다(새 주소 자체가 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)의 형태로 명칭을 흔히 볼 수 있다.


숙제

외부 API 요청 섹션의 AppMaster에서 생성하여 숙제에서 첫 번째 모듈까지 요청을 반복합니다.

  1. BoredAPI에 대한 요청을 생성합니다. 문서에서 최소 5개의 다른 매개변수를 지정하십시오. 필요한 매개변수만 지정하여 여러 다른 요청을 제출합니다.
  2. Alphavantage에 대한 요청을 작성하십시오. 매개변수를 사용하여 서로 관련하여 다른 통화의 환율을 가져옵니다.