แนวทางปฏิบัติแนะนำสำหรับการออกแบบและพัฒนาพร็อกซี API

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X info

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

นอกจากหลักเกณฑ์ที่ระบุไว้ที่นี่แล้ว คุณอาจเห็นว่าโพสต์ชุมชนรูปแบบที่ไม่ควรใช้ใน Apigee Edge มีประโยชน์เช่นกัน

มาตรฐานการพัฒนา

ความคิดเห็นและเอกสารประกอบ

  • ระบุความคิดเห็นในบรรทัดในการกำหนดค่า ProxyEndpoint และ TargetEndpoint ความคิดเห็น ช่วยให้อ่านโฟลว์ได้ง่ายขึ้น โดยเฉพาะในกรณีที่ชื่อไฟล์นโยบายอธิบาย ฟังก์ชันการทำงานพื้นฐานของโฟลว์ได้ไม่เพียงพอ
  • เขียนความคิดเห็นที่เป็นประโยชน์ หลีกเลี่ยงความคิดเห็นที่ชัดเจน
  • ใช้การเยื้อง การเว้นวรรค การจัดแนวตั้ง ฯลฯ ที่สอดคล้องกัน

การเขียนโค้ดสไตล์เฟรมเวิร์ก

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

  • หากต้องการเปิดใช้ DRY ("อย่าทำซ้ำ") การกำหนดค่านโยบายและสคริปต์ ควรใช้ฟังก์ชันเฉพาะที่นำกลับมาใช้ใหม่ได้ ตัวอย่างเช่น นโยบายเฉพาะสำหรับการแยก พารามิเตอร์การค้นหาจากข้อความคำขออาจเรียกว่า ExtractVariables.ExtractRequestParameters นโยบายเฉพาะสำหรับการแทรกส่วนหัว CORS อาจเรียกว่า AssignMessage.SetCORSHeaders จากนั้นจะจัดเก็บนโยบายเหล่านั้นไว้ในระบบควบคุมแหล่งที่มาและเพิ่มลงในพร็อกซี API แต่ละรายการที่ต้องดึงพารามิเตอร์หรือตั้งค่าส่วนหัว CORS ได้โดยไม่ต้องสร้างการกำหนดค่าที่ซ้ำซ้อน (และจัดการได้ยากกว่า)
  • ล้างนโยบายและทรัพยากรที่ไม่ได้ใช้ (JavaScript, Java, XSLT ฯลฯ) จากพร็อกซี API โดยเฉพาะทรัพยากรขนาดใหญ่ที่อาจทำให้การนำเข้าและการติดตั้งใช้งานช้าลง

รูปแบบการตั้งชื่อ

  • แอตทริบิวต์นโยบาย name และชื่อไฟล์นโยบาย XML ต้องเหมือนกัน
  • แอตทริบิวต์นโยบาย Script และ ServiceCallout name และชื่อของ ไฟล์ทรัพยากรควรเหมือนกัน
  • DisplayName ควรอธิบายฟังก์ชันของนโยบายอย่างถูกต้องแก่ผู้ที่ไม่เคยใช้พร็อกซี API นั้นมาก่อน
  • ตั้งชื่อนโยบายตามฟังก์ชันของนโยบาย Apigee ขอแนะนำให้คุณกำหนดรูปแบบการตั้งชื่อที่สอดคล้องกันสำหรับนโยบาย เช่น ใช้คำนำหน้าที่สั้นตามด้วยลำดับคำอธิบายที่คั่นด้วยขีดกลาง เช่น AM-xxx สำหรับนโยบาย AssignMessage ดูเครื่องมือ apigeelint ด้วย
  • ใช้นามสกุลที่เหมาะสมสำหรับไฟล์ทรัพยากร .js สำหรับ JavaScript, .py สำหรับ Python และ .jar สำหรับไฟล์ JAR ของ Java
  • ชื่อตัวแปรควรสอดคล้องกัน หากเลือกรูปแบบ เช่น camelCase หรือ under_score ให้ใช้รูปแบบนั้นตลอดทั้งพร็อกซี API
  • ใช้คำนำหน้าตัวแปร (หากเป็นไปได้) เพื่อจัดระเบียบตัวแปรตามวัตถุประสงค์ เช่น Consumer.username และ Consumer.password

การพัฒนาพร็อกซี API

ข้อควรพิจารณาในการออกแบบเบื้องต้น

  • ดูคำแนะนำเกี่ยวกับการออกแบบ RESTful API ได้โดยดาวน์โหลดอีบุ๊ก Web API Design: The Missing Link
  • ใช้ประโยชน์จากนโยบายและฟังก์ชันการทำงานของ Apigee Edge ทุกครั้งที่เป็นไปได้เพื่อสร้างพร็อกซี API หลีกเลี่ยงการเขียนโค้ดตรรกะพร็อกซีทั้งหมดในทรัพยากร JavaScript, Java หรือ Python
  • สร้างโฟลว์อย่างเป็นระเบียบ Flow หลายรายการซึ่งแต่ละรายการมีเงื่อนไขเดียว ดีกว่าการแนบแบบมีเงื่อนไขหลายรายการกับ PreFlow และ Postflow เดียวกัน
  • สร้างพร็อกซี API เริ่มต้นที่มี BasePath ของ ProxyEndpoint เป็น /เพื่อเป็น "การป้องกันความล้มเหลว" ซึ่งใช้เพื่อเปลี่ยนเส้นทางการเรียก API ฐานไปยังเว็บไซต์ของนักพัฒนาแอป เพื่อแสดงการตอบกลับที่กำหนดเอง หรือดำเนินการอื่นที่มีประโยชน์มากกว่าการแสดง messaging.adaptors.http.flow.ApplicationNotFound เริ่มต้น
  • ใช้ทรัพยากร TargetServer เพื่อแยกการกำหนดค่า TargetEndpoint ออกจาก URL ที่เฉพาะเจาะจง เพื่อรองรับการโปรโมตในสภาพแวดล้อมต่างๆ
    ดูการปรับสมดุลโหลด ในเซิร์ฟเวอร์แบ็กเอนด์
  • หากมี RouteRule หลายรายการ ให้สร้างรายการหนึ่งเป็น "ค่าเริ่มต้น" นั่นคือเป็น RouteRule ที่ไม่มีเงื่อนไข ตรวจสอบว่าได้กำหนด RouteRule เริ่มต้นเป็นรายการสุดท้ายในรายการเส้นทางแบบมีเงื่อนไข ระบบจะประเมิน RouteRule จากบนลงล่างใน ProxyEndpoint
    ดูเอกสารอ้างอิงการกำหนดค่าพร็อกซี API
  • ขนาดของชุดพร็อกซี API: ชุดพร็อกซี API ต้องมีขนาดไม่เกิน 15 MB ใน Apigee Edge สำหรับ Private Cloud คุณสามารถเปลี่ยนข้อจำกัดด้านขนาดได้โดยการแก้ไขพร็อพเพอร์ตี้ thrift_framed_transport_size_in_mb ในตำแหน่งต่อไปนี้ cassandra.yaml (ใน Cassandra) และ conf/apigee/management-server/repository.properties
  • การกำหนดเวอร์ชัน API: หากต้องการดูความคิดเห็นและคำแนะนำของ Apigee เกี่ยวกับการกำหนดเวอร์ชัน API โปรดดูส่วนการกำหนดเวอร์ชันใน อีบุ๊กการออกแบบ Web API: The Missing Link

การเปิดใช้ CORS

ก่อนเผยแพร่ API คุณจะต้องเปิดใช้ CORS ในพร็อกซี API เพื่อรองรับคำขอแบบข้ามต้นทางฝั่งไคลเอ็นต์

CORS (การแชร์ทรัพยากรแบบข้ามต้นทาง) เป็นกลไกมาตรฐานที่อนุญาตให้การเรียกใช้ JavaScript XMLHttpRequest (XHR) ที่ดำเนินการในหน้าเว็บโต้ตอบกับทรัพยากรจากโดเมนที่ไม่ใช่ต้นทาง CORS เป็นโซลูชันที่ใช้กันโดยทั่วไปสำหรับนโยบายต้นทางเดียวกันที่เบราว์เซอร์ทั้งหมดบังคับใช้ เช่น หากคุณเรียก XHR ไปยัง Twitter API จากโค้ด JavaScript ที่ทำงานในเบราว์เซอร์ การเรียกจะล้มเหลว เนื่องจากโดเมนที่แสดงหน้าเว็บ ในเบราว์เซอร์ของคุณไม่เหมือนกับโดเมนที่แสดง Twitter API CORS มีวิธีแก้ปัญหานี้ โดยอนุญาตให้เซิร์ฟเวอร์ "เลือกใช้" หากต้องการแชร์ทรัพยากรแบบข้ามต้นทาง

ดูข้อมูลเกี่ยวกับการเปิดใช้ CORS ในพร็อกซี API ก่อนเผยแพร่ API ได้ที่ การเพิ่มการรองรับ CORS ในพร็อกซี API

ขนาดเพย์โหลดของข้อความ

ระบบจำกัดขนาดเพย์โหลดของข้อความไว้ที่ 10 MB เพื่อป้องกันปัญหาเกี่ยวกับหน่วยความจำใน Edge การมีขนาดเกินกว่าที่ระบุจะทำให้เกิดข้อผิดพลาด protocol.http.TooBigBody

นอกจากนี้ ยังมีการพูดถึงปัญหานี้ใน โพสต์ชุมชน Apigee นี้ด้วย

กลยุทธ์ที่แนะนำสำหรับการจัดการข้อความขนาดใหญ่ใน Edge มีดังนี้

  • คำขอและการตอบกลับของสตรีม โปรดทราบว่าเมื่อคุณสตรีม นโยบายจะไม่มีสิทธิ์เข้าถึงเนื้อหาข้อความอีกต่อไป ดูคำขอและการตอบกลับแบบสตรีมมิง
  • ใน Edge for Private Cloud เวอร์ชัน 4.15.07 และก่อนหน้า ให้แก้ไขไฟล์ http.propertiesตัวประมวลผลข้อความเพื่อเพิ่มขีดจำกัดในพารามิเตอร์ HTTPResponse.body.buffer.limit โปรดทดสอบก่อนที่จะนำการเปลี่ยนแปลงไปใช้ในเวอร์ชันที่ใช้งานจริง
  • ใน Edge for Private Cloud เวอร์ชัน 4.16.01 ขึ้นไป คำขอที่มีเพย์โหลดต้องมีส่วนหัว Content-Length หรือในกรณีของการสตรีมมิง ส่วนหัว "Transfer-Encoding: chunked" สำหรับ POST ไปยังพร็อกซี API ที่มีเพย์โหลดว่างเปล่า คุณต้องส่ง Content-Length เป็น 0
  • ใน Edge for Private Cloud เวอร์ชัน 4.16.01 ขึ้นไป ให้ตั้งค่าพร็อพเพอร์ตี้ต่อไปนี้ใน /opt/apigee/router.properties หรือ message-processor.properties เพื่อเปลี่ยนขีดจำกัด ดูข้อมูลเพิ่มเติมได้ที่ ตั้งค่า ขีดจำกัดขนาดข้อความในเราเตอร์หรือ Message Processor

    พร็อพเพอร์ตี้ทั้ง 2 รายการมีค่าเริ่มต้นเป็น "10m" ซึ่งสอดคล้องกับ 10 MB ดังนี้
    • conf_http_HTTPRequest.body.buffer.limit
    • conf_http_HTTPResponse.body.buffer.limit

การจัดการข้อบกพร่อง

  • ใช้ประโยชน์จาก FaultRules เพื่อจัดการการจัดการข้อผิดพลาดทั้งหมด (ใช้นโยบาย RaiseFault เพื่อหยุด โฟลว์ข้อความและส่งการประมวลผลไปยังโฟลว์ FaultRules)
  • ภายในโฟลว์ FaultRules ให้ใช้นโยบาย AssignMessage เพื่อสร้างการตอบกลับข้อผิดพลาด ไม่ใช่นโยบาย RaiseFault เรียกใช้นโยบาย AssignMessage แบบมีเงื่อนไขตามประเภทข้อผิดพลาดที่ เกิดขึ้น
  • รวมตัวแฮนเดิลข้อผิดพลาด "ครอบคลุมทั้งหมด" เริ่มต้นเสมอเพื่อให้ข้อผิดพลาดที่ระบบสร้างขึ้นสามารถ แมปกับรูปแบบการตอบกลับข้อผิดพลาดที่ลูกค้ากำหนดได้
  • หากเป็นไปได้ ให้ตอบกลับข้อผิดพลาดให้ตรงกับรูปแบบมาตรฐานที่มีในบริษัทหรือโปรเจ็กต์ของคุณเสมอ
  • ใช้ข้อความแสดงข้อผิดพลาดที่มนุษย์อ่านได้และมีความหมายซึ่งแนะนำวิธีแก้ปัญหาข้อผิดพลาด

ดูการจัดการข้อบกพร่อง

ดูแนวทางปฏิบัติแนะนำในอุตสาหกรรมได้ที่การออกแบบการตอบกลับข้อผิดพลาดแบบ RESTful

ความต่อเนื่อง

แผนที่คีย์/ค่า

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

ดูนโยบายการดำเนินการกับแมปคีย์-ค่า

การแคชการตอบกลับ

  • อย่าป้อนข้อมูลแคชการตอบกลับหากการตอบกลับไม่สำเร็จหรือหากคำขอไม่ใช่ GET ไม่ควรแคชการสร้าง การอัปเดต และการลบ <SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation>
  • ป้อนข้อมูลลงในแคชด้วยประเภทเนื้อหาเดียวที่สอดคล้องกัน (เช่น XML หรือ JSON) หลังจาก ดึงข้อมูลรายการ responseCache แล้ว ให้แปลงเป็นประเภทเนื้อหาที่ต้องการด้วย JSONtoXML หรือ XMLToJSON ซึ่งจะช่วยป้องกันการจัดเก็บข้อมูลซ้ำ 2, 3 หรือมากกว่านั้น
  • ตรวจสอบว่าคีย์แคชเพียงพอต่อข้อกำหนดในการแคช ในหลายกรณี คุณสามารถใช้ request.querystring เป็นตัวระบุที่ไม่ซ้ำกันได้
  • อย่าใส่คีย์ API (client_id) ในคีย์แคช เว้นแต่จะมีการระบุไว้อย่างชัดเจน โดยส่วนใหญ่แล้ว API ที่รักษาความปลอดภัยด้วยคีย์เท่านั้นจะแสดงข้อมูลเดียวกันแก่ไคลเอ็นต์ทั้งหมดสำหรับคำขอหนึ่งๆ การจัดเก็บค่าเดียวกันสำหรับรายการจำนวนมากตามคีย์ API นั้นไม่มีประสิทธิภาพ
  • กำหนดช่วงเวลาหมดอายุของแคชที่เหมาะสมเพื่อหลีกเลี่ยงการอ่านข้อมูลที่ไม่ถูกต้อง
  • เมื่อใดก็ตามที่เป็นไปได้ ให้พยายามใช้นโยบายแคชการตอบกลับที่สร้างแคชให้ดำเนินการ ใน PostFlow ของการตอบกลับ ProxyEndpoint ให้ช้าที่สุด กล่าวคือ ให้ดำเนินการ หลังจากขั้นตอนการแปลและการไกล่เกลี่ย รวมถึงการไกล่เกลี่ยและการแปลงที่ใช้ JavaScript ระหว่าง JSON กับ XML การแคชข้อมูลที่สื่อกลางจะช่วยให้คุณไม่ต้องเสียค่าใช้จ่ายด้านประสิทธิภาพในการดำเนินการ ขั้นตอนสื่อกลางทุกครั้งที่เรียกข้อมูลที่แคชไว้

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

  • นโยบายแคชการตอบกลับเพื่อค้นหารายการแคชควรเกิดขึ้นใน PreFlow ของคำขอ ProxyEndpoint หลีกเลี่ยงการใช้ตรรกะมากเกินไปนอกเหนือจากการสร้างคีย์แคชก่อน ส่งคืนรายการแคช ไม่เช่นนั้นประโยชน์ของการแคชจะลดลง
  • โดยทั่วไป คุณควรให้การค้นหาแคชการตอบกลับอยู่ใกล้กับคำขอของไคลเอ็นต์มากที่สุด เท่าที่จะเป็นไปได้ ในทางกลับกัน คุณควรเก็บแคชการตอบกลับให้ใกล้เคียงกับการตอบกลับของไคลเอ็นต์มากที่สุด
  • เมื่อใช้นโยบายแคชการตอบกลับที่แตกต่างกันหลายรายการในพร็อกซี ให้ทำตามหลักเกณฑ์ต่อไปนี้ เพื่อให้มั่นใจว่าแต่ละรายการจะทำงานแยกกัน
    • บังคับใช้นโยบายแต่ละรายการตามเงื่อนไขที่แยกกัน ซึ่งจะช่วยให้มั่นใจได้ว่า จะมีการดำเนินการตามนโยบายแคชการตอบกลับเพียง 1 รายการจากหลายรายการ
    • กำหนดทรัพยากรแคชที่แตกต่างกันสำหรับนโยบายแคชการตอบกลับแต่ละรายการ คุณระบุแคช ทรัพยากรในองค์ประกอบ <CacheResource> ของนโยบาย

ดูนโยบายแคชการตอบกลับ

นโยบายและโค้ดที่กำหนดเอง

นโยบายหรือโค้ดที่กำหนดเอง

  • ใช้ในตัวก่อนเป็นอันดับแรก (เมื่อเป็นไปได้) นโยบาย Apigee ได้รับการเสริมความแข็งแกร่ง เพิ่มประสิทธิภาพ และรองรับ เช่น ใช้นโยบาย AssignMessage และ ExtractVariables มาตรฐานแทน JavaScript (หากเป็นไปได้) เพื่อสร้างเพย์โหลด แยกข้อมูลจากเพย์โหลด (XPath, JSONPath) ฯลฯ
  • ควรใช้ JavaScript มากกว่า Python และ Java อย่างไรก็ตาม หากประสิทธิภาพเป็นข้อกำหนดหลัก ควรใช้ Java แทน JavaScript

JavaScript

  • ใช้ JavaScript หากใช้งานง่ายกว่านโยบาย Apigee (เช่น เมื่อตั้งค่า target.url สำหรับชุดค่าผสม URI ที่แตกต่างกันจำนวนมาก)
  • การแยกวิเคราะห์เพย์โหลดที่ซับซ้อน เช่น การวนซ้ำผ่านออบเจ็กต์ JSON และการเข้ารหัส/ถอดรหัส Base64
  • นโยบาย JavaScript มีการจำกัดเวลา ดังนั้นระบบจึงบล็อกลูปที่ไม่มีที่สิ้นสุด
  • ใช้ขั้นตอน JavaScript เสมอและวางไฟล์ในjscโฟลเดอร์ทรัพยากร นโยบาย JavaScript ประเภทนี้จะคอมไพล์โค้ดล่วงหน้าในเวลาที่ติดตั้งใช้งาน

ดูการเขียนโปรแกรมพร็อกซี API ด้วย JavaScript

Java

  • ใช้ Java หากประสิทธิภาพเป็นสิ่งสำคัญที่สุด หรือหากไม่สามารถใช้ตรรกะใน JavaScript ได้
  • รวมไฟล์แหล่งข้อมูล Java ในการติดตามซอร์สโค้ด

ดูข้อมูลเกี่ยวกับการใช้ Java ในพร็อกซี API ได้ที่แปลงการตอบกลับ เป็นตัวพิมพ์ใหญ่ด้วยการเรียกใช้ Java และนโยบายการเรียกใช้ Java

Python

  • อย่าใช้ Python เว้นแต่จะจำเป็นจริงๆ สคริปต์ Python อาจทำให้เกิดปัญหาคอขวดด้านประสิทธิภาพ สำหรับการดำเนินการอย่างง่าย เนื่องจากมีการตีความที่รันไทม์

ข้อความเสริมของสคริปต์ (Java, JavaScript, Python)

  • ใช้ try/catch ทั่วโลกหรือเทียบเท่า
  • ส่งข้อยกเว้นที่มีความหมายและดักจับข้อยกเว้นเหล่านี้อย่างถูกต้องเพื่อใช้ในการตอบกลับข้อผิดพลาด
  • ส่งและดักจับข้อยกเว้นตั้งแต่เนิ่นๆ อย่าใช้ try/catch ทั่วโลกเพื่อจัดการข้อยกเว้นทั้งหมด
  • ทำการตรวจสอบค่า Null และค่าที่ไม่ได้กำหนดเมื่อจำเป็น ตัวอย่างกรณีที่ควรทำเช่นนี้คือเมื่อ เรียกตัวแปรโฟลว์ที่ไม่บังคับ
  • หลีกเลี่ยงการส่งคำขอ HTTP/S ภายใน Callout ของสคริปต์ ให้ใช้นโยบาย ServiceCallout ของ Apigee แทน เนื่องจากนโยบายจะจัดการการเชื่อมต่ออย่างเหมาะสม

JavaScript

  • JavaScript ในแพลตฟอร์ม API รองรับ XML ผ่าน E4X

ดูรูปแบบออบเจ็กต์ JavaScript

Java

  • เมื่อเข้าถึงเพย์โหลดของข้อความ ให้ลองใช้ context.getMessage() กับ context.getResponseMessage หรือ context.getRequestMessage ซึ่งช่วยให้มั่นใจได้ว่า โค้ดจะเรียกข้อมูลเพย์โหลดได้ทั้งในโฟลว์คำขอและคำตอบ
  • นำเข้าไลบรารีไปยังองค์กรหรือสภาพแวดล้อม Apigee Edge และอย่ารวมไลบรารีเหล่านี้ไว้ใน ไฟล์ JAR ซึ่งจะช่วยลดขนาดของ Bundle และทำให้ไฟล์ JAR อื่นๆ เข้าถึงที่เก็บไลบรารีเดียวกันได้
  • นำเข้าไฟล์ JAR โดยใช้ Apigee Resources API แทนที่จะรวมไว้ในโฟลเดอร์ทรัพยากรของพร็อกซี API ซึ่งจะช่วยลดเวลาในการติดตั้งใช้งานและอนุญาตให้พร็อกซี API หลายรายการอ้างอิงไฟล์ JAR เดียวกันได้ อีกประโยชน์หนึ่งคือการแยก Class Loader
  • อย่าใช้ Java ในการจัดการทรัพยากร (เช่น การสร้างและจัดการกลุ่มเธรด)

ดูแปลงคำตอบ เป็นตัวพิมพ์ใหญ่ด้วยการเรียกใช้ Java

Python

  • ส่งข้อยกเว้นที่มีความหมายและจับข้อยกเว้นเหล่านี้อย่างถูกต้องเพื่อใช้ในการตอบกลับข้อผิดพลาดของ Apigee

ดูนโยบาย สคริปต์ Python

ServiceCallouts

  • การใช้การเชื่อมต่อพร็อกซีมี Use Case ที่ถูกต้องหลายอย่าง ซึ่งคุณใช้การเรียกบริการใน พร็อกซี API หนึ่งเพื่อเรียกพร็อกซี API อื่น หากใช้การเชื่อมต่อพร็อกซีแบบลูกโซ่ โปรดหลีกเลี่ยงการเรียกแบบเรียกซ้ำ "ลูปอนันต์" กลับไปยังพร็อกซี API เดียวกัน

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

  • สร้างข้อความคำขอ ServiceCallout โดยใช้นโยบาย AssignMessage และป้อนข้อมูล ออบเจ็กต์คำขอในตัวแปรข้อความ (ซึ่งรวมถึงการตั้งค่าเพย์โหลดของคำขอ เส้นทาง และ เมธอด)
  • URL ที่กำหนดค่าภายในนโยบายต้องมีการระบุโปรโตคอล ซึ่งหมายความว่าส่วนโปรโตคอลของ URL เช่น https:// ไม่สามารถระบุโดยตัวแปรได้ นอกจากนี้ คุณต้องใช้ตัวแปรแยกกันสำหรับส่วนโดเมนของ URL และส่วนที่เหลือของ URL เช่น https://{domain}/{path}
  • จัดเก็บออบเจ็กต์การตอบกลับสำหรับ ServiceCallout ในตัวแปรข้อความแยกต่างหาก จากนั้นคุณจะ แยกวิเคราะห์ตัวแปรข้อความและเก็บเพย์โหลดข้อความต้นฉบับไว้เหมือนเดิมเพื่อให้ นโยบายอื่นๆ ใช้ได้

ดูนโยบายข้อความไฮไลต์บริการ

การเข้าถึงเอนทิตี

นโยบาย AccessEntity

  • ค้นหาแอปด้วย uuid แทนชื่อแอปเพื่อประสิทธิภาพที่ดียิ่งขึ้น

ดูนโยบาย Access Entity

การบันทึก

  • ใช้นโยบาย Syslog ทั่วไปในแพ็กเกจและภายในแพ็กเกจเดียวกัน ซึ่งจะช่วยให้ รูปแบบการบันทึกสอดคล้องกัน

ดูนโยบายการบันทึกข้อความ

การตรวจสอบ

ลูกค้า Cloud ไม่จำเป็นต้องตรวจสอบคอมโพเนนต์แต่ละรายการของ Apigee Edge (เราเตอร์ Message Processor ฯลฯ) ทีมปฏิบัติการทั่วโลกของ Apigee กำลังตรวจสอบคอมโพเนนต์ทั้งหมดอย่างละเอียด รวมถึงการตรวจสอบสถานะ API ตามคำขอตรวจสอบสถานะจากลูกค้า

ข้อมูลวิเคราะห์ Apigee

Analytics สามารถให้การตรวจสอบ API ที่ไม่ร้ายแรงได้เนื่องจากมีการวัดเปอร์เซ็นต์ข้อผิดพลาด

ดูแดชบอร์ดข้อมูลวิเคราะห์

Trace

เครื่องมือติดตามในUI การจัดการ API Edge มีประโยชน์สำหรับการแก้ไขข้อบกพร่องของปัญหา API ที่รันไทม์ระหว่างการพัฒนาหรือการดำเนินการในเวอร์ชันที่ใช้งานจริงของ API

ดูหัวข้อการใช้เครื่องมือติดตาม

ความปลอดภัย

  • ใช้นโยบายการจำกัดที่อยู่ IP เพื่อจำกัดการเข้าถึงสภาพแวดล้อมการทดสอบ อนุญาตการเข้าถึง สำหรับที่อยู่ IP ของเครื่องหรือสภาพแวดล้อมในการพัฒนา และไม่อนุญาตที่อยู่ IP อื่นๆ ทั้งหมด นโยบาย AccessControl
  • ใช้กับนโยบายการคุ้มครองเนื้อหา (JSON และ/หรือ XML) กับพร็อกซี API ที่ได้รับการติดตั้งใช้งาน ในการผลิตเสมอ นโยบาย JSONThreatProtection
  • ดูแนวทางปฏิบัติแนะนำด้านความปลอดภัยเพิ่มเติมได้ในหัวข้อต่อไปนี้