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

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

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

นอกจากหลักเกณฑ์ข้างต้นแล้ว โพสต์ชุมชน Apigee Edge Antipatterns อาจเป็นประโยชน์สำหรับคุณ

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

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

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

การเขียนโค้ดแบบเฟรมเวิร์ก

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

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

แบบแผนการตั้งชื่อ

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

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

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

  • หากต้องการดูคําแนะนําเกี่ยวกับการออกแบบ RESTful API ให้ดาวน์โหลด eBook เรื่อง การออกแบบ Web API: ลิงก์ที่ขาดหายไป
  • ใช้ประโยชน์จากนโยบายและฟังก์ชันการทำงานของ Apigee Edge ทุกครั้งที่ทำได้เพื่อสร้างพร็อกซี API หลีกเลี่ยงการเขียนโค้ดตรรกะของพร็อกซีทั้งหมดในทรัพยากร JavaScript, Java หรือ Python
  • สร้างโฟลว์อย่างเป็นระเบียบ กระบวนการหลายรายการที่มีเงื่อนไขเดียวเหมาะสำหรับไฟล์แนบแบบมีเงื่อนไขหลายรายการที่ PreFlow และ Postflow เดียวกัน
  • ในฐานะ "failsafe" ให้สร้างพร็อกซี API เริ่มต้นด้วย ProxyEndpoint BasePath เป็น / ซึ่งอาจใช้เพื่อเปลี่ยนเส้นทางคำขอ API ฐานไปยังเว็บไซต์ของนักพัฒนาแอป แสดงการตอบกลับที่กำหนดเอง หรือดำเนินการอย่างอื่นที่มีประโยชน์มากกว่าการแสดง messaging.adaptors.http.flow.ApplicationNotFound เริ่มต้น
  • ใช้ทรัพยากร TargetServer เพื่อแยกการกำหนดค่า TargetEndpoint จาก URL ที่เป็นรูปธรรมเพื่อสนับสนุนการโปรโมตในสภาพแวดล้อมต่างๆ
    โปรดดูหัวข้อการจัดสรรภาระงานในเซิร์ฟเวอร์แบ็กเอนด์
  • หากคุณมี RouteRule หลายรายการ ให้สร้าง 1 รายการเป็น "ค่าเริ่มต้น" ซึ่งก็คือ 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 ได้ที่การกำหนดเวอร์ชันใน eBook เรื่องการออกแบบ Web API: ลิงก์ที่ขาดหายไป

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

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

การจัดการความผิดพลาด

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

ดูการจัดการข้อผิดพลาด

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

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

การแมปคีย์/ค่า

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

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

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

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

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

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

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

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

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

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

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

JavaScript

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

ดูโมเดลออบเจ็กต์ JavaScript

Java

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

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

Python

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

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

ServiceCallouts

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

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

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

ดูนโยบายคำขอราคาเสนอบริการ

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

นโยบาย AccessEntity

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

ดูนโยบายการเข้าถึงเอนทิตี

Logging

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

โปรดดูนโยบาย MessageLในเร็วๆ นี้

Monitoring

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

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

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

ดูหน้าแดชบอร์ดของ Analytics

Trace

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

โปรดดูที่การใช้เครื่องมือติดตาม

ความปลอดภัย

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