หนึ่งในวิธีที่ดีที่สุดในการยกระดับสถานะของคุณในฐานะไฟล์ ผู้พัฒนา WordPress อย่างน้อยก็ในสายตาของลูกค้าคือการมีทักษะในการบริโภค API นี่คือสถานการณ์ทั่วไปสำหรับการใช้งาน WordPress API: ลูกค้าของคุณขอให้คุณเพิ่มวิดเจ็ตในไซต์ของพวกเขาเช่นวิดเจ็ตการสมัครอีเมล คุณรับรหัสบางส่วนจากบริการอีเมลของบุคคลที่สามซึ่งอาจเป็นแท็กสคริปต์หรือ iframe - วางโค้ดลงในหน้าเว็บและตอบกลับลูกค้าของคุณว่า“ รับทราบ!”

น่าเสียดายที่คุณกำลังติดต่อกับลูกค้าที่มีความต้องการค่อนข้างสูงและพวกเขาสังเกตเห็นความไม่สมบูรณ์ดังต่อไปนี้:

• แม้ว่าวิดเจ็ตเช่นเดียวกับส่วนอื่น ๆ ของไซต์จะมีแบบอักษร sans-serif แต่ก็ไม่ได้เป็นแบบที่ถูกต้องนัก วิดเจ็ตใช้ Helvetica แทนแบบอักษรที่กำหนดเองที่คุณติดตั้ง
• แบบฟอร์มการสมัครใช้งานของวิดเจ็ตจะทำให้เกิดการโหลดหน้าใหม่ซึ่งอาจส่งผลเสียได้หากวางไว้ครึ่งทางของบทความ
• ดูเหมือนว่าวิดเจ็ตจะใช้เวลาโหลดนานกว่านี้หลังจากส่วนที่เหลือของหน้าเว็บซึ่งให้ความรู้สึกสั่นสะเทือนและราคาถูก
• ลูกค้าต้องการให้สมาชิกติดแท็กด้วยข้อมูลเมตาตามโพสต์ที่พวกเขาสมัครรับข้อมูลและวิดเจ็ตไม่ได้นำเสนอสิ่งที่คล้ายกับฟังก์ชันนี้จากระยะไกล
• ลูกค้าพบว่ามันน่ารำคาญที่ตอนนี้พวกเขาต้องจัดการสองแดชบอร์ด (wp-admin และพื้นที่ผู้ดูแลระบบสำหรับบริการอีเมล)

ณ จุดนี้อาจมีเหตุปัจจัยหนึ่งในสองสิ่งเกิดขึ้น คุณสามารถประกาศรายการเหล่านี้ว่า“ nice-to-have” และสร้างความมั่นใจให้กับลูกค้าของคุณเกี่ยวกับข้อดีของไฟล์ โซลูชัน 80/20 หรือคุณสามารถส่งตามคำขอเหล่านั้นได้ จากประสบการณ์ส่วนตัวของฉันฉันพบว่าการส่งคำขอดังกล่าวนั่นคือการแสดงให้เห็นถึงความเชี่ยวชาญในบริการของบุคคลที่สามเป็นวิธีที่เชื่อถือได้ในการโน้มน้าวลูกค้าว่าคุณคือวิซาร์ด WordPress นอกจากนี้ยังเป็นเรื่องสนุกที่ได้ทำ

ในช่วงทศวรรษที่ผ่านมาฉันใช้ WordPress เป็นแพลตฟอร์มสำหรับการใช้ API กับ API ที่แตกต่างกัน 50 รายการ API ที่พบบ่อยที่สุด ได้แก่ MailChimp, Google Analytics, Google Maps, CloudFlare และ Bitbucket แต่ถ้าคุณต้องการทำอะไรมากกว่านี้ถ้าคุณต้องการโซลูชันที่กำหนดเองล่ะ?

วิธีการพัฒนาไคลเอ็นต์ WordPress API

ในบทความนี้ฉันจะพัฒนาให้เทียบกับ API 'บริการอีเมล' ทั่วไปโดยพยายามอย่างเต็มที่เพื่อให้สิ่งต่างๆไม่เชื่อเรื่องพระเจ้าให้มากที่สุด อย่างไรก็ตามฉันรู้สึกว่ามีเหตุผลที่จะคิดว่าเรากำลังติดต่อกับ JSON REST API นี่คือหัวข้อเบื้องหลังบางส่วนที่อาจช่วยให้คุณเพลิดเพลินกับประเด็นทางเทคนิคในบทความนี้:

• WordPress กลุ่มฟังก์ชัน HTTP
• JSON
• ส่วนที่เหลือ

หากคุณพบว่าตัวเองคุ้นเคยกับหัวข้อเหล่านี้เพียงเล็กน้อยและสนใจที่จะขุดลึกลงไปให้หยุดทันทีและดาวน์โหลดที่ยอดเยี่ยม บุรุษไปรษณีย์ ใบสมัคร ช่วยให้คุณสามารถสื่อสารกับ API ได้โดยไม่ต้องเขียนโค้ด

บุรุษไปรษณีย์. อาจเป็นเครื่องมือพัฒนาที่ฉันชอบ?

อย่างไรก็ตามหากคุณไม่คุ้นเคยกับสิ่งเหล่านี้เลยให้อ่านต่อไป ผู้ชมทางเทคนิคที่มีประสบการณ์ WordPress ระดับหนึ่งจะได้รับประโยชน์สูงสุดจากบทความนี้ แต่ฉันจะอธิบายเกี่ยวกับ มูลค่า ของแต่ละเทคนิคในทางเทคนิคน้อย ผู้อ่านที่ไม่ใช่ด้านเทคนิคจะปล่อยให้บทความนี้สามารถประเมิน ROI ของแต่ละจุดก่อนที่จะให้การสนับสนุนและตัดสินคุณภาพของการนำไปใช้เมื่อส่งมอบ

บันทึก: ในกรณีที่คุณต้องการหลักสูตรทบทวนอย่างรวดเร็วคุณสามารถดูได้ที่ คู่มือ WordPress REST API .

โดยไม่ต้องมีคำนำหน้าใด ๆ อีกต่อไปอนุญาตให้ฉันแบ่งปันเทคนิคต่างๆจำนวนหนึ่งกับคุณซึ่งฉันพบว่าตัวเองรู้สึกซาบซึ้งกับ API โครงการและทีมส่วนใหญ่ที่ฉันทำงานด้วย

ชั่วคราว: เมื่อใดควรถือไว้เมื่อใดควรพับ

ในย่อหน้าแรกของฉันฉันสังเกตว่าไคลเอนต์พบว่ามันน่ารำคาญที่ต้องคร่อมพื้นที่ผู้ดูแลระบบสองส่วน: wp-admin และแดชบอร์ดสำหรับบริการอีเมลของพวกเขา วิธีที่ดีในการแก้ไขปัญหานี้คือการให้วิดเจ็ตแดชบอร์ดใน wp-admin เพื่อแสดงสรุปกิจกรรมของสมาชิกล่าสุด

ตัวอย่างประเภทของ UI แดชบอร์ดที่เราอาจมีให้ใน WordPress เพื่อช่วยลูกค้าของเราในการเดินทางไปยังผู้ให้บริการอีเมลบุคคลที่สาม

แต่ในอีกครั้งสิ่งนี้อาจต้องใช้คำขอ HTTP หลายรายการไปยัง API ระยะไกล (API ที่ให้บริการอีเมล) ส่งผลให้โหลดหน้าเว็บเป็นเวลานาน วิธีแก้ปัญหาด้านประสิทธิภาพนี้คือการจัดเก็บการเรียก API เป็นแบบชั่วคราว นี้ บทความ Codex ให้คำอธิบายที่ดีที่คุณควรอ่านอย่างแน่นอน แต่ฉันจะสรุปให้ฟังดังนี้:

1. รับข้อมูลจาก API ระยะไกล
2. จัดเก็บโดยใช้ set_transient() ด้วยเวลาหมดอายุที่คุณเลือกขึ้นอยู่กับการตัดสินใจของคุณเองเกี่ยวกับประสิทธิภาพการ จำกัด อัตราและส่วนต่างสำหรับข้อผิดพลาดในการแสดงข้อมูลที่ล้าสมัยในแอปพลิเคชันเฉพาะนี้
3. ดำเนินการตามตรรกะทางธุรกิจของคุณ - ประมวลผลข้อมูลคืนค่าไม่ว่าในกรณีใด
4. เมื่อคุณต้องการข้อมูลอีกครั้งเช่นในการโหลดหน้าถัดไปให้ตรวจสอบในแคชชั่วคราวโดยใช้ get_transient() ก่อนที่จะสรุปว่าคุณต้องได้รับจาก API

ฉันคิดว่านี่เป็นพื้นฐานที่มีประโยชน์และเป็นไปได้ แต่คุณสามารถก้าวไปอีกขั้นได้หากคุณคิดสักครู่เกี่ยวกับคำกริยา REST ในห้าวิธีที่ใช้บ่อยที่สุด (GET, POST, PATCH, PUT, DELETE) มีเพียงวิธีเดียวเท่านั้นที่อยู่ในแคชชั่วคราวของคุณ คุณสามารถเดาได้หรือไม่? ได้รับ ในปลั๊กอินของฉันฉันมักจะมีคลาส PHP ที่อุทิศให้กับการเรียกนามธรรมไปยัง API ระยะไกลที่เป็นปัญหาและอาร์กิวเมนต์เมื่อสร้างอินสแตนซ์คลาสนั้นคือเมธอด HTTP ถ้าไม่ใช่ GET call ฉันจะไม่เรียกใช้เลเยอร์แคชใด ๆ เลย

นอกจากนี้หากไม่ใช่การโทร GET ก็เป็นเหตุผลว่าฉันกำลังดำเนินการบางอย่างเพื่อแก้ไขข้อมูลระยะไกลไม่ทางใดก็ทางหนึ่งโดยอาจเพิ่มแก้ไขหรือลบสมาชิกอีเมล นี่อาจเป็นเวลาที่ดีที่จะทำให้แคชที่มีอยู่สำหรับทรัพยากรนั้นเป็นโมฆะผ่านทาง delete_transient()

หากต้องการกลับไปที่ตัวอย่าง API การสมัครอีเมล WordPress ของเรานี่คือวิธีการทำงานในทางปฏิบัติ:

• วิดเจ็ตแดชบอร์ดสำหรับแสดงสมาชิกล่าสุดจะเรียกใช้ปลายทาง API สำหรับ /subscribers ผ่านการร้องขอ GET เนื่องจากเป็นคำขอ GET จึงถูกเก็บไว้ในแคชชั่วคราวของฉัน
• วิดเจ็ตแถบด้านข้างสำหรับการสมัครรับรายชื่ออีเมลจะเรียกใช้ปลายทาง API สำหรับ /subscribers ผ่านคำขอ POST เนื่องจากเป็นคำขอ POST ไม่เพียง แต่จะหลีกเลี่ยงแคชชั่วคราวของฉันเท่านั้น แต่ยังกระตุ้นให้ฉันลบส่วนที่เกี่ยวข้องของแคชชั่วคราวของฉันเพื่อให้วิดเจ็ตแดชบอร์ดแสดงผู้ติดตามใหม่นี้
• เมื่อตั้งชื่อชั่วคราวฉันมักจะจัดระเบียบโดยตั้งชื่อตามตัวอักษรตาม URL ระยะไกล API ที่ฉันกำลังเรียก นี่เป็นวิธีที่สะดวกในการระบุการลบชั่วคราวที่ถูกต้อง หากเป็นจุดสิ้นสุดที่รับอาร์กิวเมนต์ฉันจะเชื่อมต่อสิ่งเหล่านั้นเป็นสตริงและเพิ่มลงในชื่อชั่วคราวด้วย

ในฐานะลูกค้าหรือผู้มีส่วนได้ส่วนเสียด้านเทคนิครายอื่น ๆ คุณควรร้องขอการแคชชั่วคราวโดยเฉพาะหรืออย่างน้อยที่สุดก็คือการอภิปรายเกี่ยวกับเรื่องนี้ทุกครั้งที่แอปพลิเคชันดึงข้อมูลจากบริการระยะไกล คุณควรทำความคุ้นเคยกับสิ่งที่ยอดเยี่ยม การตรวจสอบแบบสอบถาม ปลั๊กอินเพื่อดูว่าการทำงานชั่วคราวเป็นอย่างไร มันจะให้อินเทอร์เฟซสำหรับการเรียกดูข้อมูลที่ถูกซ่อนไว้เป็นชั่วคราวความถี่และระยะเวลาเท่าใด

node.js แสดงตัวอย่าง API ส่วนที่เหลือ

บางครั้งช่วงเวลาชั่วคราวก็ไม่ดีพอ

บริการโฮสติ้ง WordPress ระดับพรีเมียมบางอย่างไม่อนุญาตให้คุณใช้ชั่วคราวในการผลิต พวกเขามีโค้ดที่ทำงานอยู่อาจอยู่ในรูปแบบของปลั๊กอิน MU หรือสคริปต์อื่น ๆ ซึ่งจะขัดขวางความพยายามของคุณในการใช้ API ชั่วคราวและจัดเก็บข้อมูลนั้นผ่านทาง แคชวัตถุ แทน. WP- เครื่องยนต์ ในการกำหนดค่าทั่วไปเป็นตัวอย่างที่สำคัญของสิ่งนี้

ภาพที่น่าตกใจใน UI ของ phpMyAdmin: ไซต์การผลิตที่ปราศจากการเปลี่ยนแปลงโดยสิ้นเชิง? ซึ่งอาจหมายความว่าการแคชอ็อบเจ็กต์กำลังทำงานอยู่

หากคุณเพียงแค่จัดเก็บและดึงข้อมูลจริงๆแล้วคุณไม่จำเป็นต้องสนใจเรื่องนี้และอาจไม่เคยสังเกตว่าเกิดขึ้น ทั้งครอบครัวของ *_transient() ฟังก์ชันจะให้ผลลัพธ์เดียวกันกับคุณเพียงกรองเพื่อใช้อ็อบเจ็กต์แคชแทนแคชชั่วคราว จุดที่คุณอาจประสบปัญหาคือเมื่อพยายามลบชั่วคราว นี่คือเหตุผล

หากการรวม API ของคุณมีความซับซ้อนเพียงพอที่จะใช้หน้าการตั้งค่าของตัวเองคุณอาจต้องการรวม UI เพื่ออนุญาตให้ผู้ใช้ที่เป็นผู้ดูแลระบบ ล้างแคชชั่วคราวทั้งหมดสำหรับปลั๊กอินของคุณ . การใช้งานปุ่มนี้โดยทั่วไปจะเกิดขึ้นเมื่อลูกค้าเปลี่ยนแปลงข้อมูลบางอย่างโดยตรงบนบริการระยะไกลและต้องการทำให้แคชที่เราจัดเก็บใน WordPress เป็นโมฆะ ปุ่มนี้อาจมีประโยชน์หากลูกค้าเปลี่ยนข้อมูลรับรองบัญชีคีย์ API หรือโดยทั่วไปเป็นปุ่ม 'รีเซ็ตเป็นค่าเริ่มต้นจากโรงงาน' สำหรับการดีบัก

ตัวอย่างของ UI ที่อนุญาตให้ไคลเอ็นต์ล้างแคชภายในสำหรับข้อมูล API ของตน

แม้ว่าคุณจะฉลาดพอที่จะเนมสเปซคีย์ชั่วคราวทั้งหมดของคุณเพื่อให้คุณมีความหวังในการระบุแต่ละคีย์สำหรับ delete_transient() แต่สถานการณ์ที่ดีที่สุดอาจยังคงเกี่ยวข้องกับ SQL ดิบซึ่งฉันพยายามหลีกเลี่ยงใน WordPress เสมอ :

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 ได้หากคุณยังไม่ใช่ผู้เชี่ยวชาญในการจัดการแคชสำหรับข้อมูลนั้น

ในฐานะไคลเอนต์สิ่งสำคัญที่ต้องระวังคือพฤติกรรมแคชที่ผิดปกติระหว่างสภาพแวดล้อมการจัดเตรียมและการใช้งานจริง กล่าวอีกนัยหนึ่งแม้ว่าการทดสอบชุดงานใหม่ในการจัดเตรียมจะเป็นแนวทางปฏิบัติที่ดีเสมอ แต่การแคชก็เป็นสิ่งที่ต้องทดสอบในการผลิตด้วยความระมัดระวังอย่างเท่าเทียมกัน

Remote 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 ซึ่งส่งคืนผลลัพธ์ที่เป็นศูนย์ถึงจำนวนมากโดยที่ผลลัพธ์แต่ละรายการเป็นสมาชิกของอาร์เรย์ นั่นอาจฟังดูค่อนข้างชัดเจน แต่ฉันพบว่ามันเป็นพรอมต์ที่มีประโยชน์สำหรับโครงสร้างคลาสต่อไปนี้ในโค้ด PHP ของฉัน:

• class.collection.php, คลาสนามธรรม
• class.subscribers.php ขยายคลาสนามธรรม Collection.
• class.lists.php ขยายคลาสนามธรรม Collection.
• class.campaigns.php ขยายคลาสนามธรรม Collection.

คลาสนามธรรมจะใช้อาร์เรย์ของพารามิเตอร์การสืบค้นเป็นอาร์กิวเมนต์เท่านั้น: สิ่งต่างๆเช่นการแบ่งหน้าคอลัมน์การเรียงลำดับการเรียงลำดับและตัวกรองการค้นหา มันจะมีวิธีการสำหรับงานทั่วไปเช่นการเรียก API ระยะไกลการจัดการข้อผิดพลาดและอาจเปลี่ยนผลลัพธ์เป็น HTMLmenu หรือ jQueryUI AutoSuggest คลาสที่สร้างอินสแตนซ์คลาสนามธรรมอาจค่อนข้างสั้นบางทีทำมากกว่าการระบุสตริงที่จะใช้ในไฟล์ *.json URL ปลายทางของ 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

พวกเขาทั้งหมดส่งคืนไฟล์ สิ่งของ โดยที่ฉันหมายถึงสมาชิกที่เฉพาะเจาะจงและไม่ซ้ำใครของคอลเลกชัน: สิ่งต่างๆเช่นสมาชิกอีเมลหนึ่งรายชื่ออีเมลหนึ่งรายการหรือแคมเปญอีเมลหนึ่งแคมเปญ ดังนั้นฉันต้องการใช้โครงสร้างต่อไปนี้ในโค้ด PHP ของฉัน:

• class.item.php, คลาสนามธรรม
• class.subscriber.php ขยายคลาสนามธรรม Item.
• class.list.php ขยายคลาสนามธรรม Item.
• class.campaign.php ขยายคลาสนามธรรม Item.

คลาสนามธรรมจะใช้เป็นสตริงอาร์กิวเมนต์เพื่อระบุรายการเฉพาะที่ต้องการ อีกครั้งคลาสที่กำลังสร้างอินสแตนซ์อาจค่อนข้างสั้นบางทีอาจทำมากกว่าการระบุสตริงที่จะใช้ใน */duy736td.json

มีหลายวิธีในการจัดโครงสร้างการสืบทอดคลาส แต่แม้ว่าคุณจะใช้วิธีการอื่นกับสิ่งที่ฉันได้ระบุไว้ข้างต้นฉันเดิมพันว่ามีโอกาสดีที่โครงสร้างของ API ระยะไกลจะช่วยแจ้งโครงสร้างของแอปพลิเคชันของคุณได้

ในฐานะลูกค้าอาการทั่วไปของสถาปัตยกรรมที่ไม่ดีคือเมื่อคุณพบว่าตัวเองต้องร้องขอการเปลี่ยนแปลงแบบเดียวกันซ้ำแล้วซ้ำเล่าในแอปพลิเคชัน ตัวอย่างเช่นหากคุณขอให้รายงานแสดงผลลัพธ์ 100 รายการต่อหน้าแทนที่จะเป็น 10 รายการและคุณต้องทำซ้ำคำขอนั้นสำหรับรายงานสมาชิกรายงานแคมเปญรายงานการยกเลิกการสมัคร ฯลฯ คุณอาจตรวจพบสถาปัตยกรรมคลาสที่ไม่ดี ในสถานการณ์เช่นนี้ควรถามทีมของคุณว่าพวกเขาจะได้รับประโยชน์จากวงจรการปรับโครงสร้างหรือไม่: เนื้องานที่เป้าหมายไม่ได้อยู่ที่การเปลี่ยนแปลงพฤติกรรมของผลิตภัณฑ์ แต่เป็นการปรับปรุงโค้ดพื้นฐานเพื่อให้เปลี่ยนพฤติกรรมได้ง่ายขึ้น ของผลิตภัณฑ์ในอนาคต

กรณีการใช้งานที่สมบูรณ์แบบสำหรับ WP_Error

ฉันรู้สึกอายที่ต้องยอมรับว่าฉันใช้เวลานานหลายปีกว่าที่ควรจะต้องเริ่มใช้ไฟล์ WP_Error ตระกูลฟังก์ชันในรหัสของฉัน ฉันมักจะเขียนโค้ดในแบบของฉันไม่ว่าจะไม่มีข้อผิดพลาดที่ควรค่าแก่การดูแลเกี่ยวกับการเขียนโปรแกรมหรือจัดการเป็นกรณี ๆ ไป การทำงานกับ API ระยะไกลจะตัดความคิดนั้นออกไปเช่นลำแสงเลเซอร์เนื่องจากเป็นกรณีการใช้งานที่สะดวกและมีประสิทธิภาพอย่างยิ่งสำหรับการใช้ WP_Error

จำได้ว่าก่อนหน้านี้ฉันพูดถึงฉันมักจะมีคลาส PHP ที่มีจุดประสงค์เพื่อส่งคำขอ HTTP ไปยัง API ระยะไกล เมื่อคุณลอกเอกสารสำเร็จรูปทั้งหมดการจัดการข้อมูลทั้งหมดข้อกังวลรองทั้งหมดคลาสนั้นจะเรียก wp_remote_request() เพื่อรับวัตถุตอบสนอง HTTP จาก API สะดวก, wp_remote_request() จะส่งกลับ WP_Error แทน หากการโทรล้มเหลวด้วยเหตุผลบางประการ แต่จะเกิดอะไรขึ้นหากการโทรประสบความสำเร็จในการส่งคืนการตอบสนอง HTTP ของประเภทที่ไม่เอื้ออำนวย

ในทางเทคนิคเรียก API ทำงาน แต่ก็ไม่ใช่ว่าจะไม่มีข้อแม้ คำเตือนเหล่านี้จำเป็นต้องได้รับการบันทึกและรายงานอย่างสม่ำเสมอตลอดทั้ง codebase

ตัวอย่างเช่นบางทีเราโทรไปที่ /lists.json endpoint แต่บัญชีนี้ยังไม่มีการตั้งค่ารายการใด ๆ สิ่งนี้จะส่งคืนการตอบสนอง HTTP ที่ถูกต้อง แต่มีรหัสสถานะ 400 แม้ว่าจะไม่ใช่ข้อผิดพลาดร้ายแรงต่อตัวก็ตามจากมุมมองของโค้ดส่วนหน้าบางส่วนที่ต้องการเปลี่ยนการเรียก API นี้ให้เป็นเมนูแบบเลื่อนลง แต่ 400 อาจ เช่นกันจะเป็น WSOD ! ดังนั้นฉันพบว่ามีประโยชน์ในการแยกวิเคราะห์เพิ่มเติมเกี่ยวกับผลลัพธ์ของ wp_remote_request() ซึ่งอาจส่งคืน WP_Error หลังจากนั้น:

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 ของตัวเองได้กลายเป็นเวทีที่มีประสิทธิภาพอย่างไม่น่าเชื่อสำหรับโค้ด แต่คุณภาพที่แม่นยำนี้สามารถทำให้ช้าได้เช่นกัน

คำสั่งใน angularjs คืออะไร?

เป็นเรื่องปกติที่คำขอ HTTP ระยะไกลจะเป็นส่วนที่ใช้เวลานานที่สุดในการโหลดหน้าเว็บหนึ่ง ๆ ด้วยเหตุนี้ส่วนประกอบที่ขับเคลื่อนด้วย API จำนวนมากจึงทำงานผ่าน Ajax หรือ cron ตัวอย่างเช่นคำแนะนำอัตโนมัติสำหรับการค้นหาผ่านรายชื่อผู้สมัครรับข้อมูลอีเมลน่าจะส่ง Ping ไปยังแหล่งข้อมูลระยะไกลตามความต้องการตามการกดแป้นแต่ละครั้งแทนที่จะโหลดสมาชิกทั้งหมด 100,000 คนภายใน DOM เมื่อหน้าโหลด หากนั่นไม่ใช่ตัวเลือกบางทีข้อความค้นหาขนาดใหญ่อาจซิงโครไนซ์กับงาน cron ทุกคืนเพื่อให้ดึงผลลัพธ์จากมิเรอร์ภายในเครื่องแทนที่จะเป็น API ระยะไกล

ปัญหาของแนวทางนี้คือการดีบักอาจเป็นเรื่องยาก แทนที่จะเปิด WP_DEBUG และปล่อยให้ข้อความแสดงข้อผิดพลาดเข้าสู่หน้าต่างเบราว์เซอร์ของคุณคุณกำลังมองหาในคอนโซลเครือข่ายของเบราว์เซอร์หรือกำหนดไฟล์บันทึกเป็นงาน cron (หวังว่า?) กำลังดำเนินการอยู่ ฉันรู้สึกอึดอัดนี้

วิธีหนึ่งในการปรับปรุงสถานการณ์นี้คือการโทรอย่างระมัดระวังและมีกลยุทธ์ error_log() . แต่อีกครั้งปัญหาทั่วไปในการบันทึกคือด้วยแอปพลิเคชันขนาดใหญ่หรือไม่ว่างบันทึกข้อผิดพลาดอาจมีขนาดใหญ่เกินไปหรือเติบโตเร็วเกินไปเพื่อเป็นประโยชน์ในการตรวจสอบหรือแยกวิเคราะห์ ดังนั้นเราต้องเลือกสิ่งที่เราบันทึก ใช้ความคิดให้มากพอ ๆ กับตรรกะแอปพลิเคชันจริงของเรา . เป็นเรื่องน่าเสียดายที่ต้องใช้เวลาในการบันทึกข้อผิดพลาดกรณีขอบที่แปลกใหม่ซึ่งดูเหมือนว่าจะเกิดขึ้นเป็นระยะ ๆ ในงาน cron ที่ไม่บ่อยนักเพียงเพื่อให้ตระหนักว่าลักษณะที่แท้จริงของข้อผิดพลาดได้หลบเลี่ยงคุณอีกครั้งเนื่องจากคุณล้มเหลวในการบันทึกสมาชิกอาร์เรย์บางตัว กล่าวถึงมูลค่าที่กระทำผิด

ดังนั้นปรัชญาของฉันจึงกลายเป็น ฉันไม่ได้บันทึกเสมอไป แต่เมื่อฉันทำฉันจะบันทึกทุกอย่าง . กล่าวอีกนัยหนึ่งคือหลังจากระบุฟังก์ชันที่น่าเป็นห่วงแล้วฉันจะบันทึกด้วยเน็ตที่กว้างที่สุดเท่าที่จะทำได้:

var_dump()

จำนวนนี้เป็น

|_+_|

‘รวมค่าบั๊กกี้ทั้งหมดไว้ในรายการเดียวในไฟล์บันทึกข้อผิดพลาด

บันทึกข้อผิดพลาดที่มีขนาดใหญ่เกินกว่าที่จะเหมาะกับการทำงานสำหรับการดีบัก

ในฐานะลูกค้าคุณควรตรวจสอบการใช้หน่วยความจำไฟล์ทั้งหมดสำหรับแอปพลิเคชันของคุณเป็นระยะ หากคุณสังเกตเห็นว่าคุณกำลังใช้พื้นที่เก็บข้อมูลในบัญชีโฮสติ้งของคุณอย่างกระทันหันมีโอกาสที่ดีที่บันทึกข้อผิดพลาดจะเกิดขึ้นอย่างรุนแรง นักพัฒนาของคุณจะได้รับประโยชน์จากวงจรการทำงานที่เน้นการบันทึกที่ดีขึ้นและลูกค้าของคุณก็จะได้รับประโยชน์เช่นกัน!

ไม่ใช่ Clickbait อย่างตรงไปตรงมา แต่ก็ทำได้

โปรดยกโทษโครงสร้างรายชื่อของบทความนี้ ฉันไม่สามารถบังคับให้ประเด็นเหล่านี้กลายเป็นธีมบทความที่เป็นหนึ่งเดียวได้มากขึ้นเนื่องจากรูปแบบเหล่านี้เป็นแบบทั่วไป: ใช้กับปลายทาง JSON REST และเอาต์พุต WordPress ใด ๆ .

รูปแบบเหล่านี้เป็นรูปแบบที่ฉันเห็นเกิดขึ้นซ้ำแล้วซ้ำเล่าไม่ว่า API ระยะไกลคืออะไรหรือสิ่งที่เราใช้ใน WordPress ก็ตาม ฉันได้ไปไกลถึงขั้นรวบรวมหลักการเหล่านี้ทั้งหมดไว้ในปลั๊กอินต้นแบบที่ช่วยเร่งงานของฉันได้อย่างมาก คุณมีจุดที่คล้ายกันที่คุณเก็บไว้สำหรับแต่ละโครงการหรือไม่? โปรดแบ่งปันเพื่อที่ฉันจะได้ขโมยพวกเขาและเพิ่มลงในสำเร็จรูปของฉัน!

ที่เกี่ยวข้อง: วิธีการพัฒนา WordPress สมัยใหม่ (ตอนที่ 1)

ทำความเข้าใจพื้นฐาน

WordPress REST API คืออะไร

วิธีที่สะดวกสำหรับการใช้ WordPress เพื่อเผยแพร่ API API นี้สามารถใช้โดยไซต์ WordPress อื่น ๆ ไซต์อื่น ๆ ที่ไม่ใช่ WordPress หรือแม้แต่ไซต์เผยแพร่เอง นี่เป็นแนวทางยอดนิยมสำหรับการใช้ WordPress เป็น CMS แบบ 'หัวขาด' หรือแม้แต่สำหรับผู้ฟัง Ajax ขนาดเล็ก

คีย์ API บน WordPress คืออะไร?

คีย์ API เป็นวิธีทั่วไปในการจัดการการพิสูจน์ตัวตน WordPress API เข้ากันได้กับหลายวิธีในการตรวจสอบสิทธิ์ หนึ่งในนั้นคือปลั๊กอิน WordPress REST API OAuth ซึ่งให้อินเทอร์เฟซสำหรับจัดการคีย์ API แก่ผู้ใช้

WP-JSON คืออะไร?

WP-JSON สามารถคิดได้ว่าเป็นพี่น้องของมุมมอง RSS ของ WordPress พร้อมกับมุมมองส่วนหน้าปกติ เป็นอีกวิธีหนึ่งในการส่งออกข้อมูล WordPress แม้ว่าผู้อ่านส่วนใหญ่จะไม่ต้องการใช้ WordPress ในรูปแบบนี้ แต่จุดประสงค์คือการใช้งานโดยไคลเอนต์ API