이 시리즈에서는 wp_remote_get WordPress HTTP API 함수를 조사하여 작동 방식, 사용 방법 및 허용되는 선택적 매개 변수를 이해합니다.
여기에서 자세한 요청을 작성할 수 있지만 응답도 절반에 불과합니다.
두 번째 글에서는 기본 응답이 어떤 모습인지, 어떻게 평가하는지, 화면에 어떻게 표시하는지 살펴보았지만, 실제로 응답에 대해 자세히 다루지는 않았습니다. p>
더 고급 요청을 작성하고 더 방어적인 코드를 작성하려면 응답으로 전송되는 데이터를 이해하는 것이 중요합니다. 마지막 기사에서 우리는 바로 그 일을 할 것입니다.
먼저 방어 코드를 작성한다는 것이 무슨 뜻인지 이해하는 것이 중요합니다. 소프트웨어를 작성할 때 사용자가 뭔가 잘못하거나, 입력이 잘못 설정되거나, 데이터가 검색되거나 수신될 수 있는 상황을 처리해야 하는 경우가 많습니다. 응답의 경우 - 올바르지 않습니다.
이를 위해 우리는 사용자가 소프트웨어를 사용하는 동안 소프트웨어가 완전히 충돌하거나 충돌하지 않도록 이러한 시나리오에 대해 방어적으로 코딩합니다. 대신 정상적으로 실패하고 계속 실행됩니다.
요청에 대한 응답으로 함수가 무엇을 받는지 정확히 알면 어떤 데이터를 찾아야 할지 알 수 있으며, 예상대로 함수가 반환되지 않을 때 상황을 우아하게 처리하는 방법도 알 수 있습니다.
무슨 일이 일어날지 대비하기 위해 샘플 응답을 살펴보겠습니다. 간단한 텍스트를 반환하는 URL에 대한 GET 요청을 한다고 가정해 보겠습니다.
일반적으로 응답이 XML, JSON 또는 다른 것일 수 있는 더 복잡한 요청을 할 수 있지만 해당 정보는 모두 응답 배열의 body 인덱스에 설정됩니다. 따라서 무엇을 기대해야 할지 안다면 이를 처리하는 방법도 알 수 있습니다.
즉, 이는 일반 텍스트만 반환하는 도메인에 대한 간단한 요청에서 받을 것으로 예상되는 응답입니다.
으아악는 배열(또는 실제로는 배열의 배열)에 지나지 않습니다. 역시 나쁠 건 없겠죠?
각 반응형 요소를 자세히 살펴보겠습니다.
위 응답에서 볼 수 있듯이 헤더는 실제로 추가 정보를 포함하는 또 다른 배열로 구성됩니다.
위의 각 정보를 살펴보기 전에 헤더가 정확히 무엇인지 이해하는 것이 중요합니다. 간단히 말해서 헤더는 클라이언트와 서버 사이에 존재하는 요청/응답 통신에 대한 정보를 제공합니다.
다시 보낼 수 있는 다양한 헤더가 있지만(그 중 대부분은 이 문서의 범위를 벗어남), 모두 요청뿐만 아니라 요청에 대한 서버에 대한 정보를 얻는 데 도움이 됩니다. 우리는 소통하고 있습니다.
이제 각 헤더 요소를 자세히 살펴보겠습니다.
분명히 이것은 이해하기 매우 쉬운 요소입니다. 간단히 말해서 메시지가 전송된 날짜와 시간입니다. 분명히 세계 시간 표준인 그리니치 표준시(Greenwich Mean Time)의 요일, 날짜 및 시간이 포함됩니다.
서버 요소는 서버가 실행하는 소프트웨어 유형을 나타냅니다. 일반적으로 Apache가 표시될 수 있지만 현재 IIS 및 곧 출시될 nginx와 같은 다른 서버 애플리케이션도 사용할 수 있습니다.
X-Powered-By는 통신 트랜잭션을 지원하는 서버 소프트웨어를 의미합니다. 우리의 경우에는 PHP가 표시되는데, 이는 단순히 요청이 Apache와 PHP를 실행하는 서버로 전송된다는 의미입니다.
그러나 항상 그런 것은 아닙니다.
예를 들어 nginx 및 Python을 실행하는 서버 또는 Ruby on Rails를 실행하는 다른 유형의 서버 소프트웨어와 통신하게 될 수 있습니다.
이 특정 응답 요소는 요청이 전송된 서버의 IP 주소를 나타냅니다. 이 특정 정보를 알아야 하는 경우는 거의 없습니다. 그러나 다른 모든 정보가 올바른 것처럼 보임에도 불구하고 예상치 못한 응답을 받게 되는 경우 서버의 IP가 요청이 전송될 것으로 예상하는 도메인과 일치하는지 아는 것이 도움이 될 수 있습니다. .
요청이 이루어지고 응답이 전송될 때마다 응답에는 수명 주기가 있다고 할 수 있습니다.
더 구체적으로 말하면, 일정 시간이 지나면 응답은 "오래된" 것으로 간주됩니다. 분명히 응답이 오래된 것으로 간주되는 시간은 응답이 만료된 것으로 간주되는 시간입니다.
응답이 오래되지 않은 것으로 간주되는 시간은 서버 구성에 따라 다르지만 타임스탬프는 요청 날짜와 동일한 형식입니다.
캐시 제어는 웹 브라우저(또는 클라이언트와 서버 사이에 존재하는 다른 캐싱 메커니즘)가 첫 번째 응답을 향후 요청에 대한 응답으로 사용할 수도 있고 사용하지 않을 수도 있다는 개념을 나타냅니다. p>
예를 들어, 서버 응답 no-cache，则意味着请求机器的浏览器、服务器或其他代理软件或缓存机制必须将每个响应视为新响应。另一方面，如果 no-cache이 지정되지 않은 경우 첫 번째 응답은 얻을 수 있는 유일한 응답일 수 있습니다(적어도 캐시가 만료되도록 설정될 때까지
이것은 분명히 두 개의 인덱스로 구성됩니다:
no-cache설정 여부post-check 和 pre-check 간격이 만료되면 업데이트된 데이터 버전이 요청되고, 그렇지 않으면 캐시된 버전이 검색됩니다. 캐싱의 특정 측면은 이 시리즈의 범위를 벗어납니다. 더 많은 내용을 작성하고 설명할 수 있지만 위의 정의는 보고 있는 헤더를 설명하는 데 충분합니다.
이 헤더 값은 요청 서버에 유사한 후속 요청을 처리하는 방법을 알려준다는 점에서 Cache-Control 헤더와 유사합니다.
일반적으로 이는 캐시된 응답을 사용할 수 있는지, 아니면 새 값을 검색해야 하는지 서버에 알려줍니다. 이는 지나치게 복잡해질 수 있는 또 다른 요소이지만, 설명을 더 넓은 범위로 추출하기 위해 다양한 헤더 요소는 서버가 기대하는 다양한 콘텐츠 유형을 서버에 나타낼 수도 있습니다. Client가 처리할 수 있습니다.
위의 예에서 우리는 클라이언트가 인코딩된 정보를 처리할 수 있음을 서버에 지시하고 있습니다.
Content-length는 캐치가 있는 간단한 개념입니다. 먼저 응답 본문의 길이를 정의합니다.
문제는 8비트 바이트로 수행된다는 것입니다. 이는 응답이 킬로바이트, 메가바이트 또는 우리가 일반적으로 보는 어떤 형태의 데이터로도 제공되지 않음을 의미합니다.
이를 위해 반환된 데이터에 대한 더 풍부한 정보를 수집하려면 일부 변환을 수행해야 할 수도 있습니다.
연결 값은 요청하는 브라우저가 선호하는 연결 유형을 지정합니다. 위에서 값은 "close"로 정의되어 있으며, 이는 응답이 전송되면 연결이 닫힐 수 있음을 의미합니다.
그러나 다른 옵션도 있습니다. 예를 들어, 분명히 한동안 연결을 유지하려는 "keep-alive"를 수신할 수 있습니다.
이것은 완전히 논의하기 위해 자체 기사가 필요한 또 다른 예입니다. 그러나 이는 서버가 선호하는 연결 유형에 대한 통찰력을 제공하여 향후 요청을 구성하는 데 도움이 될 수 있습니다.
이 내용은 POST 和 PUSH 요청에만 해당됩니다. 즉, 이는 요청의 본문 유형을 정의합니다.
전송되는 데이터에 따라 달라질 수 있습니다. 때로는 인코딩된 URL일 수도 있고, 때로는 PHP일 수도 있고, 때로는 다른 것일 수도 있습니다. 그럼에도 불구하고 이는 콘텐츠에 반환된 데이터가 요청에 따라 예상한 것과 일치하는지 확인할 수 있도록 도와줍니다.
body 요소에는 실제로 서버에서 반환된 정보가 포함되어 있습니다.
이전 두 기사의 예에서는 Twitter로부터 JSON 문자열을 받았습니다. 위의 예에서는 간단한 텍스트 문자열을 받았습니다. 궁극적으로 응답은 어느 정도 역직렬화가 필요한 일종의 이진 데이터 형식으로 반환될 수 있습니다.
그럼에도 불구하고 응답을 사용자에게 표시하기 전에 응답을 적절하게 디코딩하는 방법을 이해하는 것은 요청 구현자로서 우리의 책임입니다.
응답은 실제로 서버에서 요청 클라이언트로 다시 전송되는 HTTP 응답 코드를 나타냅니다. HTTP 상태 코드에 익숙하지 않다면 HTTPStat.us에서 아주 좋은 참고 자료를 확인하는 것이 좋습니다.
간단히 말하면 응답은 숫자 코드와 요청 결과를 나타내는 텍스트 기반 메시지로 구성됩니다.
위의 예에서는 "200" 상태 코드와 "OK" 메시지를 받은 것을 볼 수 있습니다. 코드와 메시지 통신은 항상 서로 동기화됩니다.
즉, "403"을 받으면 "금지됨" 메시지도 받아야 하고, "404"를 받으면 "찾을 수 없음" 메시지도 받아야 한다는 뜻입니다.
개인적으로는 이러한 특정 값이 내가 요청한 내용에 문제가 있는지 진단하는 데 매우 중요하다고 생각합니다.
마지막으로 쿠키 배열은 현재 클라이언트와 통신하는 서버 사이에 존재하는 쿠키를 기반으로 네트워크를 통해 전송되는 모든 정보를 의미합니다.
요청의 성격에 따라 이 항목은 비어 있을 수도 있고 비어 있지 않을 수도 있습니다. 명확한 지침을 제공하기에는 사례별로 너무 많이 달라집니다. 즉, 두 연결 사이에 쿠키가 설정되지 않으면 연결은 항상 비어 있을 가능성이 높습니다. 그렇지 않으면 쿠키 배열을 구성하는 데이터는 두 서비스 사이에 존재하는 쿠키에만 기반하게 됩니다.
전반적으로 데이터의 양이 상당히 많으며, 수신하도록 요청한 내용과 서버의 응답에 따라 데이터 는 요청마다 달라질 수 있습니다. 그러나 문제는 이제 무엇을 기대하고 어떻게 해야 하는지 알고 있다는 것입니다. 모든 사건을 올바르게 처리하십시오.
상황이 더 악화되면 언제든지 디버거를 사용하거나 print_r 或 var_dump와 같은 디버그 문을 입력하여 서버가 무엇을 반환하는지 확인하고 오류를 적절하게 처리할 수 있습니다.
나중에 WordPress HTTP API를 다시 방문하여 wp_remote_post 和 wp_remote_request와 같은 다른 방법을 확인하여 HTTP API에 대한 완전한 이해를 갖도록 하겠습니다.
그때까지 이 시리즈는 여러분의 작업을 개선하는 데 도움이 될 뿐만 아니라 원격 요청과 관련하여 무엇이 가능한지에 대한 호기심을 불러일으킬 wp_remote_get에 대한 가장 심층적인 소개를 제공할 것입니다.
위 내용은 WordPress HTTP API 살펴보기: wp_remote_get 및 해당 응답에 대해 알아보기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
