แนวทางปฏิบัติแนะนำสำหรับการออกแบบและพัฒนาพร็อกซี 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 ต้องเหมือนกัน
  • แอตทริบิวต์ name ของนโยบายสคริปต์และ ServiceCallout และชื่อไฟล์ทรัพยากรควรเหมือนกัน
  • 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: องค์ประกอบที่ขาดหายไป
  • ใช้ประโยชน์จากนโยบายและฟังก์ชันการทำงานของ Apigee Edge ทุกครั้งที่เป็นไปได้เพื่อสร้างพร็อกซี API หลีกเลี่ยงการเขียนโค้ดตรรกะพร็อกซีทั้งหมดในทรัพยากร JavaScript, Java หรือ Python
  • สร้างโฟลว์อย่างเป็นระเบียบ การใช้โฟลว์หลายรายการโดยแต่ละรายการมีเงื่อนไขเดียวจะดีกว่าการแนบไฟล์แบบมีเงื่อนไขหลายรายการไปยังโฟลว์ก่อนและหลังเดียวกัน
  • โปรดสร้างพร็อกซี API เริ่มต้นที่มี BasePath ของ ProxyEndpoint เป็น / เป็น "แผนสำรอง" ซึ่งสามารถใช้เพื่อเปลี่ยนเส้นทางคำขอ API พื้นฐานไปยังเว็บไซต์ของนักพัฒนาแอป เพื่อแสดงคำตอบที่กำหนดเอง หรือดำเนินการอื่นที่มีประโยชน์มากกว่าการแสดงmessaging.adaptors.http.flow.ApplicationNotFoundเริ่มต้น
  • ใช้ทรัพยากร TargetServer เพื่อแยกการกําหนดค่า TargetEndpoint ออกจาก URL ที่เจาะจง ซึ่งรองรับการโปรโมตในสภาพแวดล้อมต่างๆ
    ดูการปรับสมดุลภาระงานในเซิร์ฟเวอร์แบ็กเอนด์
  • หากคุณมี RouteRule หลายรายการ ให้สร้างรายการหนึ่งเป็น "ค่าเริ่มต้น" กล่าวคือเป็น RouteRule ที่ไม่มีเงื่อนไข ตรวจสอบว่า RouteRule เริ่มต้นได้รับการกําหนดไว้เป็นรายการสุดท้ายในรายการเส้นทางแบบมีเงื่อนไข ระบบจะประเมิน RouteRules จากบนลงล่างใน ProxyEndpoint
    ดูข้อมูลอ้างอิงเกี่ยวกับการกำหนดค่าพร็อกซี API
  • ขนาดพูลพร็อกซี API: พูลพร็อกซี API ต้องมีขนาดไม่เกิน 15 MB ใน Apigee Edge สําหรับระบบคลาวด์ส่วนตัว คุณสามารถเปลี่ยนขีดจํากัดขนาดได้โดยแก้ไขพร็อพเพอร์ตี้ 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 (Cross-Origin Resource Sharing) เป็นกลไกมาตรฐานที่อนุญาตให้การเรียกใช้ XMLHttpRequest (XHR) ของ JavaScript ที่ดำเนินการในหน้าเว็บโต้ตอบกับทรัพยากรจากโดเมนที่ไม่ใช่ต้นทาง 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 เพื่อเปลี่ยนขีดจํากัด ดูข้อมูลเพิ่มเติมได้ที่หัวข้อตั้งค่าขีดจำกัดขนาดข้อความในเราเตอร์หรือโปรแกรมประมวลผลข้อความ

    พร็อพเพอร์ตี้ทั้ง 2 รายการมีค่าเริ่มต้นเป็น "10m" ซึ่งสอดคล้องกับ 10MB ดังนี้
    • 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 วิธีนี้จะช่วยป้องกันการจัดเก็บข้อมูลซ้ำ 3 ครั้งขึ้นไป
  • ตรวจสอบว่าคีย์แคชเพียงพอตามข้อกำหนดการแคช ในหลายกรณี request.querystring สามารถใช้เป็นตัวระบุที่ไม่ซ้ำได้
  • อย่าใส่คีย์ API (client_id) ไว้ในคีย์แคช เว้นแต่จะต้องระบุไว้อย่างชัดเจน ในกรณีส่วนใหญ่ API ที่รักษาความปลอดภัยด้วยคีย์เท่านั้นจะแสดงผลข้อมูลเดียวกันแก่ไคลเอ็นต์ทั้งหมดสำหรับคำขอหนึ่งๆ การเก็บค่าเดียวกันสําหรับรายการจํานวนมากตามคีย์ API นั้นไม่มีประสิทธิภาพ
  • กำหนดช่วงเวลาหมดอายุของแคชที่เหมาะสมเพื่อหลีกเลี่ยงการอ่านที่ไม่ถูกต้อง
  • เมื่อเป็นไปได้ ให้พยายามใช้นโยบายแคชคำตอบที่ป้อนข้อมูลแคชให้ทำงานในขั้นตอนหลังการตอบสนองของ ProxyEndpoint ให้ช้าที่สุด กล่าวคือ ให้เรียกใช้หลังจากขั้นตอนแปลภาษาและสื่อกลาง ซึ่งรวมถึงสื่อกลางและการเปลี่ยนรูปแบบจาก JSON เป็น XML ที่ใช้ JavaScript การแคชข้อมูลที่สื่อกลางจะช่วยหลีกเลี่ยงต้นทุนด้านประสิทธิภาพของการดำเนินการขั้นตอนสื่อกลางทุกครั้งที่คุณดึงข้อมูลที่แคชไว้

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

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

ดูนโยบายแคชคำตอบ

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

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

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

JavaScript

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

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 เดียวกัน

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

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

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

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

นโยบาย AccessEntity

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

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

การบันทึก

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

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

การตรวจสอบ

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

Apigee Analytics

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

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

Trace

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

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

ความปลอดภัย

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