외부 API 요청

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

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

외부 API 요청 생성

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

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

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

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

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

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

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

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

쿼리 매개변수

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

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

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

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

또 다른 사용 사례는 데이터 양을 제한하는 것입니다. 예를 들어 일부 목록에 액세스할 수 있지만 그 목록에서 처음 5개 항목만 요청할 수 있습니다. 이 수량은 쿼리 매개변수일 수도 있습니다.

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

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

헤더

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

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

신체

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