WordPress API 개발자가 사용하지 않는 5가지 전투 테스트 기술

게시 됨: 2022-03-11

적어도 클라이언트의 관점에서 WordPress 개발자로서의 지위를 높이는 가장 좋은 방법 중 하나는 API 사용에 능숙해지는 것입니다. 다음은 WordPress API 구현에 대한 일반적인 시나리오입니다. 클라이언트가 예를 들어 이메일 구독 위젯과 같은 위젯을 사이트에 추가하도록 요청합니다. 타사 이메일 서비스에서 일부 코드(스크립트 태그 또는 iframe 일 수 있음)를 가져와 페이지에 붙여넣고 클라이언트에게 "알았습니다!"라고 회신합니다.

불행히도, 당신은 다소 까다로운 고객을 상대하고 있으며 다음과 같은 불완전성을 인지합니다.

  • 사이트의 나머지 부분과 마찬가지로 위젯에도 산세리프 글꼴이 포함되어 있지만 올바른 글꼴은 아닙니다. 위젯이 설치한 사용자 정의 글꼴 대신 Helvetica를 사용하고 있습니다.
  • 위젯의 구독 양식은 새 페이지 로드를 트리거하며, 기사 중간에 배치하면 중단될 수 있습니다.
  • 위젯은 페이지의 나머지 부분 이후에 로드하는 데 추가 시간이 걸리는 것 같으며 거슬리고 저렴하게 느껴집니다.
  • 클라이언트는 구독자가 구독한 게시물을 기반으로 메타데이터로 태그를 지정하기를 원하며 위젯은 이 기능과 원격으로 유사한 것을 제공하지 않습니다.
  • 클라이언트는 이제 두 개의 대시보드(wp-admin 및 이메일 서비스의 관리 영역)를 관리해야 하는 것이 짜증스럽습니다.

이 시점에서 두 가지 중 하나가 합리적으로 발생할 수 있습니다. 이러한 항목을 "있으면 좋은 것"이라고 선언하고 80/20 솔루션의 장점에 대해 고객을 안심시키거나 이러한 요청을 이행할 수 있습니다. 내 개인적인 경험에 따르면 이러한 요청을 전달하는 것, 즉 타사 서비스에 대한 숙달을 입증하는 것이 고객에게 당신이 일종의 WordPress 마법사임을 확신시키는 신뢰할 수 있는 방법이라는 것을 알게 되었습니다. 게다가, 종종 하는 것이 재미있습니다.

지난 10년 동안 저는 WordPress를 50가지 다른 API에 대한 API 소비 플랫폼으로 사용해 왔습니다. 가장 일반적인 API 중 일부는 MailChimp, Google Analytics, Google Maps, CloudFlare 및 Bitbucket입니다. 하지만 더 많은 작업을 수행해야 하는 경우 사용자 지정 솔루션이 필요한 경우에는 어떻게 해야 합니까?

WordPress API 클라이언트를 개발하는 방법

이 기사에서는 가능한 한 불가지론적인 것을 유지하기 위해 최선을 다하면서 일반 "이메일 서비스" API에 대해 개발할 것입니다. 그러나 우리가 JSON REST API를 다루고 있다고 가정하는 것이 합리적이라고 생각합니다. 다음은 이 문서의 기술적인 요점을 즐기는 데 도움이 될 수 있는 몇 가지 배경 주제입니다.

  • WordPress HTTP 함수 제품군
  • JSON
  • 쉬다

이러한 주제에 약간 익숙하고 더 깊이 파고드는 데 관심이 있다면 지금 일시 중지하고 우수한 Postman 응용 프로그램을 다운로드하십시오. 코드를 작성하지 않고도 API와 통신할 수 있습니다.

Postman 대시보드의 스크린샷

우편 집배원. 내가 가장 좋아하는 개발 도구가 아닐까요?

그러나 그것들에 전혀 익숙하지 않다면 어쨌든 계속 읽으십시오. 어느 정도 WordPress 경험이 있는 기술 청중은 이 기사를 최대한 활용할 수 있지만 덜 기술적인 방식으로 각 기술의 가치 를 설명하겠습니다. 기술에 익숙하지 않은 독자는 이 기사를 후원하기 전에 각 포인트의 ROI를 평가하고 일단 전달되면 구현 품질을 판단할 수 있도록 남겨둘 것입니다.

참고: 빠른 복습 과정이 필요한 경우 WordPress REST API 가이드를 확인할 수 있습니다.

더 이상의 서문 없이, 제가 작업하는 대부분의 모든 API, 프로젝트 및 팀에서 제가 높이 평가하는 몇 가지 다른 기술을 공유하겠습니다.

트랜지언트: 잡아야 할 때, 접어야 할 때

첫 단락에서 나는 클라이언트가 wp-admin과 이메일 서비스용 대시보드라는 두 가지 관리 영역에 걸쳐 있는 것이 성가신 것을 발견했다고 언급했습니다. 이를 해결하는 좋은 방법은 wp-admin에서 대시보드 위젯을 제공하여 최근 구독자 활동에 대한 요약을 표시하는 것입니다.

wp-admin 대시보드 위젯의 스크린샷

고객이 타사 이메일 서비스 제공업체를 방문하지 않도록 하기 위해 WordPress 내에서 제공할 수 있는 대시보드 UI 유형의 예입니다.

그러나 이 경우에도 원격 API(이메일 서비스에서 제공하는 API)에 대한 여러 HTTP 요청이 필요할 수 있으며 결과적으로 긴 페이지 로드가 발생할 수 있습니다. 이 성능 문제에 대한 해결책은 API 호출을 일시적으로 저장하는 것입니다. 이 Codex 기사는 반드시 읽어야 할 훌륭한 설명을 제공하지만 다음과 같이 요약하겠습니다.

  1. 원격 API에서 데이터를 가져옵니다.
  2. 이 특정 응용 프로그램에서 오래된 데이터를 표시할 때 발생하는 성능, 속도 제한 및 오류 마진에 대한 자신의 판단에 따라 선택한 만료 시간과 함께 set_transient() 를 사용하여 저장합니다.
  3. 어떤 경우이든 데이터를 처리하고 값을 반환하는 비즈니스 로직을 진행하십시오.
  4. 다음 페이지 로드와 같이 데이터가 다시 필요한 경우 API에서 가져와야 한다고 결론을 내리기 전에 get_transient() 를 사용하여 임시 캐시에서 데이터를 확인합니다.

나는 이것이 유용하고 실행 가능한 기초라고 생각하지만 REST 동사에 대해 잠시 생각한다면 한 걸음 더 나아갈 수 있습니다. 가장 일반적인 5가지 방법(GET, POST, PATCH, PUT, DELETE) 중 하나만 임시 캐시에 속합니다. 어느 쪽인지 짐작이 가시나요? GET입니다. 내 플러그인에는 거의 항상 문제의 원격 API에 대한 추상화 호출 전용 PHP 클래스가 있으며 해당 클래스를 인스턴스화할 때의 인수는 HTTP 메서드입니다. GET 호출이 아니면 캐싱 계층을 전혀 호출하지 않을 것입니다.

또한 GET 호출이 아닌 경우 이메일 구독자를 추가, 편집 또는 제거하여 원격 데이터를 변경하는 조치를 취하는 것이 당연합니다. 지금이 delete_transient() 를 통해 해당 리소스에 대한 기존 캐시를 무효화하기에 좋은 시간일 수 있습니다.

WordPress 이메일 구독 API의 예로 돌아가서 실제로 작동하는 방법은 다음과 같습니다.

  • 최근 구독자를 표시하는 대시보드 위젯은 GET 요청을 통해 /subscribers 에 대한 API 끝점을 호출합니다. GET 요청이기 때문에 임시 캐시에 저장됩니다.
  • 이메일 목록을 구독하기 위한 사이드바 위젯은 POST 요청을 통해 /subscribers 에 대한 API 끝점을 호출합니다. POST 요청이기 때문에 임시 캐시를 피할 수 있을 뿐만 아니라 임시 캐시의 관련 부분을 삭제하도록 유도하여 대시보드 위젯이 이 새 구독자를 반영하도록 합니다.
  • 일시적인 이름을 지정할 때 호출하는 원격 API URL을 따서 문자 그대로 이름을 지정하여 구성하는 경우가 많습니다. 이것은 삭제할 올바른 트랜션트를 식별하는 편리한 방법입니다. 인수를 사용하는 끝점인 경우 이를 문자열로 연결하고 임시 이름에도 추가합니다.

클라이언트 또는 기타 덜 기술적인 이해 관계자는 애플리케이션이 원격 서비스에서 데이터를 가져올 때마다 일시적인 캐싱을 요청하거나 최소한 이에 대한 논의를 요청해야 합니다. 과도 상태가 어떻게 작동하는지 보려면 우수한 쿼리 모니터 플러그인에 익숙해져야 합니다. 어떤 데이터가 일시적으로, 얼마나 자주, 얼마나 오랫동안 숨겨져 있는지 찾아볼 수 있는 인터페이스를 제공합니다.

때때로 일시적인 효과가 충분하지 않습니다.

일부 프리미엄 WordPress 호스팅 서비스는 실제로 프로덕션에서 일시적인 사용을 허용하지 않습니다. 그들은 MU 플러그인이나 다른 스크립트의 형태로 실행 중인 코드를 가지고 있는데, 이 코드는 트랜션트 API를 사용하려는 시도를 가로채고 대신 개체 캐시를 통해 해당 정보를 저장합니다. 가장 일반적인 구성의 WP-Engine이 이에 대한 대표적인 예입니다.

캡션에 설명된 phpMyAdmin 보기의 스크린샷

phpMyAdmin UI의 놀라운 광경: 일시적인 현상이 전혀 없는 프로덕션 사이트? 이는 개체 캐싱이 작동 중임을 의미합니다.

단순히 데이터를 저장하고 검색하는 경우에는 실제로 이에 대해 신경 쓸 필요가 없으며 이러한 일이 발생한다는 사실조차 알아차리지 못할 수도 있습니다. *_transient() 함수의 전체 제품군은 일시적인 캐시 대신 개체 캐시를 사용하도록 필터링된 동일한 최종 결과를 제공합니다. 그러나 문제가 발생할 수 있는 곳은 일시적인 항목을 삭제하려고 할 때입니다. 여기 이유가 있습니다.

API 통합이 자체 설정 페이지를 사용할 만큼 충분히 복잡한 경우 관리자 가 플러그인의 전체 임시 캐시를 지울 수 있도록 UI를 포함할 수 있습니다. 이 버튼의 가장 일반적인 용도는 클라이언트가 원격 서비스에서 직접 일부 데이터를 변경하고 WordPress에 저장하고 있는 캐시를 무효화하려는 경우입니다. 이 버튼은 클라이언트가 계정 자격 증명, API 키를 변경하거나 일반적으로 디버깅을 위한 "공장 초기화" 버튼으로 변경하는 경우에도 유용할 수 있습니다.

옵션 버튼의 스크린샷

클라이언트가 API 데이터에 대한 로컬 캐시를 비울 수 있도록 하는 UI의 예입니다.

모든 임시 키의 이름을 지정할 만큼 똑똑했더라도 delete_transient() 에 대해 각각을 식별할 수 있는 희망을 가질 수 있다고 해도 최상의 시나리오에는 여전히 원시 SQL이 포함될 수 있습니다.

 <?php // Purge all the transients associated with our plugin. function purge() { global $wpdb; $prefix = esc_sql( $this -> get_transient_prefix() ); $options = $wpdb -> options; $t = esc_sql( "_transient_timeout_$prefix%" ); $sql = $wpdb -> prepare ( " SELECT option_name FROM $options WHERE option_name LIKE '%s' ", $t ); $transients = $wpdb -> get_col( $sql ); // For each transient... foreach( $transients as $transient ) { // Strip away the WordPress prefix in order to arrive at the transient key. $key = str_replace( '_transient_timeout_', '', $transient ); // Now that we have the key, use WordPress core to the delete the transient. delete_transient( $key ); } } ?>

편리하지 않고 효율적이지 않습니다. 대신 이 상황에서는 객체 캐싱이 필요합니다 . 객체 캐싱은 캐시된 값을 함께 그룹화하는 편리한 방법을 제공하기 때문 입니다. 이렇게 하면 플러그인과 관련된 모든 캐시된 값을 비워야 할 때 wp_cache_delete( $key, $group ) 에 대한 간단한 한 줄 호출입니다.

이 모든 것을 요약하면 다음과 같습니다. 아직 해당 데이터의 캐시 관리 전문가가 아닌 경우 API 사용 전문가가 될 수 없습니다.

클라이언트로서 주의해야 할 핵심은 스테이징 환경과 프로덕션 환경 간의 비정상적인 캐시 동작입니다. 다시 말해서, 스테이징에서 새로운 작업 배치를 테스트하는 것이 항상 좋은 방법이지만 캐싱은 동일한 주의를 기울여 프로덕션에서도 테스트해야 하는 것입니다.

원격 API는 PHP 클래스 계층 구조를 알려주는 데 도움이 될 수 있습니다.

내 플러그인에 대한 다양한 PHP 클래스를 배치할 때 API 엔드포인트가 정의된 방식을 모방하는 것이 도움이 되는 경우가 종종 있습니다. 예를 들어 다음 엔드포인트의 공통점은 무엇입니까?

  • https://api.example-email-service.com/v1/subscribers.json
  • https://api.example-email-service.com/v1/lists.json
  • https://api.example-email-service.com/v1/campaigns.json

그들은 모두 컬렉션 을 반환합니다. 즉, GET 요청의 결과를 의미하며 각 결과가 배열의 구성원인 0-대-다 결과를 반환합니다. 상당히 당연하게 들릴지 모르지만 내 PHP 코드에서 다음 클래스 구조에 대한 유용한 프롬프트임을 알았습니다.

  • class.collection.php , 추상 클래스
  • class.subscribers.php 는 추상 클래스인 Collection 을 확장합니다.
  • class.lists.php 는 추상 클래스인 Collection 을 확장합니다.
  • class.campaigns.php 는 추상 클래스인 Collection 을 확장합니다.

추상 클래스는 페이지 매김, 정렬 열, 정렬 순서 및 검색 필터와 같은 쿼리 매개변수의 배열을 유일한 인수로 사용합니다. 원격 API 호출, 오류 처리, 결과를 HTML <select> 메뉴 또는 jQueryUI AutoSuggest로 모핑하는 것과 같은 일반적인 작업을 위한 메서드가 있습니다. 추상 클래스를 인스턴스화하는 클래스는 매우 짧을 수 있습니다. 아마도 *.json API 끝점 URL에서 사용할 문자열을 지정하는 것 이상일 것입니다.

Mailchimp API 플레이그라운드의 스크린샷

Mailchimp는 API 호출 등을 샌드박싱하기 위한 API "놀이터"를 게시합니다. 또한 API의 전체 데이터 계층 구조를 탐색하는 편리한 방법으로 작동하여 자체 클래스 계층 구조를 구성하는 방법에 대한 유용한 정보를 제공합니다.

마찬가지로 다음 끝점의 공통점은 무엇입니까?

  • https://api.example-email-service.com/v1/subscribers/104abyh4.json
  • https://api.example-email-service.com/v1/lists/837dy1h2.json
  • https://api.example-email-service.com/v1/campaigns/9i8udr43.json

그것들은 모두 item 을 반환하는데, 정확히 하나의 특정 이메일 구독자, 하나의 이메일 목록 또는 하나의 이메일 캠페인과 같은 컬렉션의 특정 고유한 구성원을 의미합니다. 따라서 PHP 코드에서 다음 구조를 사용하고 싶습니다.

  • class.item.php , 추상 클래스
  • class.subscriber.php 는 추상 클래스인 Item 을 확장합니다.
  • class.list.php 는 추상 클래스인 Item 을 확장합니다.
  • class.campaign.php 는 추상 클래스인 Item 을 확장합니다.

추상 클래스는 요청되는 특정 항목을 식별하기 위해 문자열을 유일한 인수로 사용합니다. 다시 한 번, 인스턴스화되는 클래스는 매우 짧을 수 있으며 아마도 */duy736td.json 에서 사용할 문자열을 지정하는 것 이상을 수행하지 않을 수 있습니다.

클래스 상속을 구조화하는 방법에는 여러 가지가 있지만 위에서 설명한 것과 다른 접근 방식을 취하더라도 원격 API의 구조가 애플리케이션의 구조를 알리는 데 도움이 될 수 있는 좋은 기회가 있다고 확신합니다.

클라이언트로서 열악한 아키텍처의 일반적인 증상은 애플리케이션에서 동일한 변경을 계속해서 요청해야 하는 경우입니다. 예를 들어 보고서에서 페이지당 10개가 아닌 100개의 결과를 반환하도록 요청하고 구독자 보고서, 캠페인 보고서, 구독 취소 보고서 등에 대해 해당 요청을 계속 반복해야 하는 경우 불량한 클래스 아키텍처를 감지할 수 있습니다. 이 상황에서 팀에 리팩토링 주기의 이점이 있는지 물어볼 가치가 있습니다. 목표가 제품의 동작을 변경하는 것이 아니라 기본 코드를 개선하여 동작을 변경하기 쉽도록 하는 작업 본체 앞으로의 제품의.

WP_Error 의 완벽한 사용 사례

내 코드에서 WP_Error 계열 함수를 제대로 사용하기 시작하는 데 몇 년이 더 걸렸다는 사실을 인정하는 것이 부끄럽습니다. 프로그래밍 방식으로 처리할 가치가 있는 오류가 없다고 가정하거나 사례별로 처리하는 방식으로 코드를 작성하는 경향이 있습니다. 원격 API로 작업하면 WP_Error 사용에 대한 매우 편리하고 강력한 사용 사례를 제공하기 때문에 레이저 빔과 같은 사고 방식을 절단합니다.

내가 종종 원격 API에 HTTP 요청을 하는 것이 목적인 PHP 클래스가 있다고 언급했던 것을 상기하십시오. 모든 상용구, 모든 데이터 조작, 모든 부차적인 문제를 제거하면 해당 클래스는 실제로 API에서 HTTP 응답 객체를 얻기 위해 wp_remote_request() 를 호출하는 것으로 귀결됩니다. 편리하게도 wp_remote_request() 는 호출이 어떤 이유로 실행되지 않으면 대신 WP_Error 를 반환하지만 호출이 성공하지 못한 유형의 HTTP 응답을 반환하는 데 성공하면 어떻게 될까요?

구독 양식 스크린샷

기술적으로 말하면 API 호출이 작동 했지만 주의 사항이 완전히 없는 것은 아닙니다. 이러한 경고는 코드베이스 전체에서 일관된 방식으로 캡처 및 보고되어야 합니다.

예를 들어 /lists.json 엔드포인트를 호출했지만 이 특정 계정에는 아직 설정된 목록이 없습니다. 이것은 유효한 HTTP 응답을 반환하지만 상태 코드는 400입니다. 그 자체로 치명적인 오류는 아니지만 이 API 호출을 드롭다운 메뉴로 전환하려는 일부 프런트 엔드 코드의 관점에서 볼 때 400은 뿐만 아니라 WSOD! 따라서 wp_remote_request() 의 결과에 대해 추가 구문 분석을 수행하는 것이 도움이 되며 결국 WP_Error 를 반환할 가능성이 있습니다.

 <?php function call() { $response = wp_remote_request( $this -> url, $this -> args ); $code = wp_remote_retrieve_response_code( $response ); $first_digit = $code[0]; $good_responses = array( 2, 3 ); if( ! in_array( $first_digit, $good_responses ) { $body = wp_remote_retrieve_body( $response ); $out = new WP_Error( $code, $body ); } else { $out = $response; } return $out; } ?>

이 패턴은 호출자 클래스를 호출하는 코드를 단순화하는 데 도움이 될 수 있습니다. 출력을 진행하기 전에 is_wp_error() 에 안전하게 의존할 수 있다는 것을 알고 있기 때문입니다.

클라이언트로서 때때로 악의적인 사용자, 혼란스러운 사용자, 참을성이 없는 사용자의 역할을 수행해야 합니다. 의도하지 않은 방식으로 앱을 사용합니다. 개발자가 원하지 않는 일을 하십시오. 무슨 일이 일어나는지 기록해 두십시오. 유용한 오류 메시지를 받습니까? 오류 메시지가 전혀 표시되지 않습니까? 그렇지 않다면 더 나은 오류 처리를 위한 일련의 작업을 후원할 가치가 있습니다.

ob_get_clean() 의 아름다운 디버깅 능력

거의 모든 사이트가 다른 사이트의 API를 사용하고 자체 API를 통해 자체적으로 사용되는 최신 프로그래밍 가능 웹은 코드를 위한 믿을 수 없을 정도로 강력한 영역이 되었습니다. 그러나 속도를 상당히 느리게 만들 수 있는 것은 바로 이 품질입니다.

원격 HTTP 요청은 주어진 페이지 로드에서 가장 시간이 많이 걸리는 부분인 것이 일반적입니다. 이러한 이유로 많은 API 기반 구성 요소는 Ajax 또는 cron을 통해 실행됩니다. 예를 들어, 이메일 구독자 목록을 검색하기 위한 자동 제안은 페이지가 로드될 때 DOM 내에서 100,000명의 모든 구독자를 로드하는 대신 각 키 입력 시 필요에 따라 원격 데이터 소스를 ping해야 합니다. 이것이 옵션이 아닌 경우 야간 cron 작업에서 대규모 쿼리를 동기화하여 원격 API가 아닌 로컬 미러에서 결과를 가져올 수 있습니다.

이 접근 방식의 문제는 디버깅이 어려울 수 있다는 것입니다. 단순히 WP_DEBUG 를 켜고 오류 메시지가 브라우저 창에 표시되도록 하는 대신 브라우저 네트워크 콘솔을 보거나 cron 작업(잘하면?)이 실행 중일 때 로그 파일을 추적하는 데 갇히게 됩니다. 나는 이것이 불편하다.

이 상황을 개선하는 한 가지 방법은 error_log() 를 신중하고 전략적으로 호출하는 것입니다. 그러나 다시 말하지만, 로깅의 일반적인 문제는 크거나 사용량이 많은 응용 프로그램에서 오류 로그가 모니터링 또는 구문 분석에 유용하기에는 너무 커지거나 너무 빨리 커질 수 있다는 것입니다. 따라서 실제 응용 프로그램 논리와 마찬가지로 기록할 항목을 선택적으로 고려해야 합니다. 일부 특정 배열 구성원을 기록하는 데 실패했기 때문에 버그의 진정한 본질이 다시 한 번 당신을 회피했다는 사실을 깨닫기 위해 드물게 일부 cron 작업에서 간헐적으로만 발생하는 것으로 보이는 일부 이국적인 예외 사례 오류를 기록하는 데 시간이 걸리는 것은 유감입니다. , 말하자면, 위반 가치.

따라서 내 철학은 항상 기록하지는 않지만 기록할 때 모든 것을 기록한다는 것 입니다. 다시 말해서, 특히 걱정스러운 기능을 식별한 후 가능한 한 넓은 네트를 사용하여 기록할 것입니다.

 <?php function debug( $bug ) { ob_start(); var_dump( $bug ); $out = ob_get_clean(); error_log( $out ); } ?>

이는 전체 버그 값을 오류 로그 파일의 단일 항목으로 '화하는 var_dump() '에 해당합니다.

오류 로그 파일의 스크린샷

디버깅을 위해 인체 공학적으로 너무 커진 오류 로그.

클라이언트로서 애플리케이션의 총 파일 메모리 사용량을 주기적으로 확인하는 것이 좋습니다. 갑자기 호스팅 계정의 저장 용량 제한에 부딪히게 된다면 오류 로그가 잘못되었을 가능성이 큽니다. 개발자는 더 나은 로깅에 중점을 둔 작업 주기의 이점을 누릴 수 있으며 고객도 마찬가지입니다!

정확히 클릭베이트는 아니지만 그렇게 할 것입니다.

이 기사의 목록 구조를 용서하십시오. 이러한 패턴은 매우 일반적이기 때문에 이러한 요점을 보다 통합된 기사 테마로 강제할 수 없습니다. 모든 JSON REST 끝점 및 WordPress 출력에 적용됩니다 .

원격 API가 무엇인지 또는 WordPress 내에서 사용하는 것과 관계없이 계속해서 발생하는 패턴입니다. 나는 이러한 모든 종류의 원칙을 내 작업을 크게 가속화하는 플러그인 상용구로 수집하기까지 했습니다. 각 프로젝트에 대해 유지하는 유사한 포인트가 있습니까? 내가 훔쳐서 내 상용구에 추가할 수 있도록 공유해 주세요!

관련: 최신 WordPress 개발에 접근하는 방법(1부)