คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล
คำสั่งแบบมีเงื่อนไขเป็นโครงสร้างการควบคุมทั่วไปในภาษาโปรแกรมทั้งหมด การกำหนดค่าพร็อกซี API รองรับคำสั่งแบบมีเงื่อนไขสำหรับโฟลว์ นโยบาย ขั้นตอน และ RouteRule เหมือนกับภาษาโปรแกรม การกำหนดคำสั่งแบบมีเงื่อนไขถือเป็นการกำหนดลักษณะการทำงานแบบไดนามิกสำหรับ API ลักษณะการทำงานแบบไดนามิกนี้ช่วยให้คุณทำสิ่งต่างๆ ได้ เช่น แปลง XML เป็น JSON สำหรับอุปกรณ์เคลื่อนที่เท่านั้น หรือกำหนดเส้นทางไปยัง URL แบ็กเอนด์ตามประเภทเนื้อหาหรือคำกริยา HTTP ของข้อความคำขอ
หัวข้อนี้จะแสดงวิธีใช้เงื่อนไขเพื่อใช้ฟีเจอร์การจัดการ API แบบไดนามิกระหว่างรันไทม์โดยไม่ต้องเขียนโค้ด
กำหนดค่าคำสั่งแบบมีเงื่อนไข
ลักษณะการทำงานแบบมีเงื่อนไขจะนำไปใช้ในพร็อกซี API โดยใช้conditionsและconditionsร่วมกัน คำสั่งแบบมีเงื่อนไขจะสร้างขึ้นโดยใช้องค์ประกอบเงื่อนไข ต่อไปนี้เป็นเงื่อนไขที่ว่างเปล่า
<Condition></Condition>
หากต้องการสร้างคำสั่งแบบมีเงื่อนไข คุณต้องเพิ่มโอเปอเรเตอร์และตัวแปรแบบมีเงื่อนไขเพื่อสร้างโครงสร้างต่อไปนี้
<Condition>{variable.name}{operator}{"value"}</Condition>
โอเปอเรเตอร์แบบมีเงื่อนไขที่รองรับ ได้แก่ =
(เท่ากับ), !=
(ไม่เท่ากับ) และ >
(มากกว่า) คุณยังเขียนเงื่อนไขเป็นข้อความ equals
, notequals
, greaterthan
เพื่อให้อ่านง่ายขึ้นได้ด้วย
คุณจะใช้ ~/
หรือ MatchesPath
ได้เมื่อทำงานกับเส้นทาง URI นอกจากนี้ คุณยังจับคู่นิพจน์ทั่วไปของ JavaRegex กับโอเปอเรเตอร์ ~~ ได้ด้วย
เงื่อนไขใช้เพื่อกำหนดโฟลว์แบบมีเงื่อนไขของพร็อกซี API ไปยังทรัพยากรแบ็กเอนด์ API ดังที่อธิบายไว้ในหัวข้อสร้างโฟลว์แบบมีเงื่อนไขสำหรับทรัพยากร API แบ็กเอนด์ ดูรายการเงื่อนไขทั้งหมดของเงื่อนไขได้ที่ข้อมูลอ้างอิงเงื่อนไข
ตัวแปร
เงื่อนไขจะทำงานโดยการประเมินค่าของตัวแปร ตัวแปรคือพร็อพเพอร์ตี้ของธุรกรรม HTTP ที่ดำเนินการโดยพร็อกซี API หรือพร็อพเพอร์ตี้ของการกำหนดค่าพร็อกซี API เอง เมื่อใดก็ตามที่พร็อกซี API ได้รับคำขอจากแอป Apigee Edge จะเติมข้อมูลรายการตัวแปรจำนวนมากที่เชื่อมโยงกับสิ่งต่างๆ เช่น เวลาของระบบ, ข้อมูลเครือข่ายของแอป, ส่วนหัว HTTP ในข้อความ, การกำหนดค่าพร็อกซี API, การดำเนินการนโยบาย และอื่นๆ วิธีนี้จะสร้างบริบทที่สมบูรณ์ที่คุณสามารถใช้เพื่อตั้งค่าคำสั่งแบบมีเงื่อนไข
ตัวแปรจะใช้สัญลักษณ์ที่มีจุดเสมอ เช่น ส่วนหัว HTTP ในข้อความคำขอจะแสดงเป็นตัวแปรที่เรียกว่า request.header.{header_name}
ดังนั้นในการประเมินส่วนหัวประเภทเนื้อหา คุณอาจใช้ตัวแปร request.header.Content-type
ได้ เช่น request.header.Content-type = "application/json"
บ่งบอกว่าประเภทเนื้อหาของคำขอควรเป็น JSON
สมมติว่าคุณต้องสร้างคำสั่งแบบมีเงื่อนไขที่จะทำให้มีการบังคับใช้นโยบายเฉพาะเมื่อข้อความคำขอเป็น GET หากต้องการสร้างเงื่อนไขที่ประเมินคำกริยา HTTP ของคำขอ คุณจะต้องสร้างคำสั่งแบบมีเงื่อนไขที่ด้านล่าง ตัวแปรในเงื่อนไขนี้คือ request.verb
ค่าของตัวแปรคือ GET
โอเปอเรเตอร์คือ =
<Condition>request.verb = "GET"</Condition>หรือคุณยังสามารถใช้สิ่งต่อไปนี้
<Condition>request.verb equals "GET"</Condition>
Edge ใช้ข้อความดังกล่าวเพื่อประเมินเงื่อนไขต่างๆ ตัวอย่างด้านบนจะประเมินค่าเป็นจริง หากกริยา HTTP ที่เชื่อมโยงกับคำขอคือ GET หากกริยา HTTP ที่เชื่อมโยงกับคำขอเป็น POST คำสั่งจะประเมินค่าเป็นเท็จ
หากต้องการเปิดใช้ลักษณะการทำงานแบบไดนามิก ให้แนบเงื่อนไขไว้กับโฟลว์ ขั้นตอน และ Route Rules
เมื่อคุณแนบเงื่อนไขกับโฟลว์ คุณจะสร้าง "โฟลว์แบบมีเงื่อนไข" โฟลว์แบบมีเงื่อนไขจะทำงานเมื่อเงื่อนไขประเมินเป็น "จริง" เท่านั้น คุณจะแนบนโยบายได้มากเท่าที่ต้องการในกระบวนการแบบมีเงื่อนไข โฟลว์แบบมีเงื่อนไขช่วยให้คุณสร้างกฎการประมวลผลแบบพิเศษสำหรับข้อความคำขอหรือข้อความตอบกลับที่ตรงตามเกณฑ์ที่กำหนดได้
ตัวอย่างเช่น หากต้องการสร้างโฟลว์ที่จะดำเนินการเฉพาะเมื่อคำกริยาคำขอเป็น GET ให้ทำดังนี้
<Flows> <Flow name="ExecuteForGETs"> <Condition>request.verb="GET"</Condition> </Flow> </Flows>
วิธีสร้างโฟลว์สำหรับ GET และอีก 1 โฟลว์สำหรับ POST
<Flows> <Flow name="ExecuteForGETs"> <Condition>request.verb="GET"</Condition> </Flow> <Flow name="ExecuteForPOSTs"> <Condition>request.verb="POST"</Condition> </Flow> </Flows>
ดังที่แสดงในตัวอย่างด้านล่าง คุณสามารถใช้เงื่อนไขกับขั้นตอนนโยบายได้ เงื่อนไขต่อไปนี้จะทำให้มีการบังคับใช้นโยบาย ConfirmApiKey ต่อเมื่อข้อความคำขอเป็น POST เท่านั้น
<PreFlow name="PreFlow"> <Request> <Step> <Condition>request.verb equals "POST"</Condition> <Name>VerifyApiKey</Name> </Step> </Request> </PreFlow>
เมื่อกำหนดโฟลว์แบบมีเงื่อนไขดังกล่าวแล้ว คุณจะแนบนโยบายกับโฟลว์ได้ การเปิดใช้พร็อกซี API เพื่อบังคับใช้นโยบายชุดหนึ่งสำหรับคำขอ GET และนโยบายอีกชุดสำหรับคำขอ POST
สำหรับข้อมูลอ้างอิงที่ครอบคลุม โปรดดูแหล่งข้อมูลต่อไปนี้
ตัวอย่างที่ 1
ตัวอย่างต่อไปนี้แสดงโฟลว์แบบมีเงื่อนไขรายการเดียวชื่อ Convert-for-devices
ซึ่งกำหนดค่าในขั้นตอนการตอบกลับ ProxyEndpoint เพิ่มเงื่อนไขเป็นองค์ประกอบลงในเอนทิตีที่จะใช้เงื่อนไข ในตัวอย่างนี้ เงื่อนไขเป็นคอมโพเนนต์ของโฟลว์
ดังนั้น โฟลว์จะทำงานทุกครั้งที่คำสั่งประเมินเป็นจริง
<Flows> <Flow name="Convert-for-devices"> <Condition>(request.header.User-Agent = "Mozilla")</Condition> <Response> <Step><Name>ConvertToJSON</Name></Step> </Response> </Flow> </Flows>
Edge จะจัดเก็บค่าของส่วนหัว HTTP ทั้งหมดที่แสดงเป็นตัวแปรสำหรับคำขอแต่ละรายการที่ได้รับจากแอป หากคำขอมีส่วนหัว HTTP ที่เรียกว่า User-Agent
ระบบจะจัดเก็บส่วนหัวและค่านั้นเป็นตัวแปรที่ชื่อ request.header.User-Agent
จากการกำหนดค่า ProxyEndpoint ข้างต้น Edge จะตรวจสอบค่าของตัวแปร request.header.User-Agent
เพื่อดูว่าเงื่อนไขประเมินค่าเป็นจริงหรือไม่
หากเงื่อนไขประเมินเป็น "จริง" นั่นก็คือค่าของตัวแปร request.header.User-Agent
เท่ากับ Mozilla
โฟลว์แบบมีเงื่อนไขจะทำงานและบังคับใช้นโยบาย XMLtoJSON ที่เรียกว่า ConvertToJSON
มิเช่นนั้น ระบบจะไม่ดำเนินการโฟลว์และจะส่งคืนการตอบสนอง XML ไม่มีการแก้ไข (ในรูปแบบ XML) ไปยังแอปที่ส่งคำขอ
ตัวอย่างที่ 2
ลองใช้ตัวอย่างที่คุณต้องเปลี่ยนรูปแบบข้อความตอบกลับจาก XML เป็น JSON แต่เฉพาะในอุปกรณ์เคลื่อนที่เท่านั้น ก่อนอื่น ให้สร้างนโยบายที่จะแปลงการตอบกลับในรูปแบบ XML จาก Weather API เป็น JSON โดยทำดังนี้
<XMLToJSON name="ConvertToJSON"> <Options> </Options> <OutputVariable>response</OutputVariable> <Source>response</Source> </XMLToJSON>
การกำหนดค่านโยบายด้านบนจะบอกให้พร็อกซี API รับข้อความตอบกลับ ดำเนินการแปลงจาก XML เป็น JSON ด้วยการตั้งค่าเริ่มต้น จากนั้นเขียนผลลัพธ์ลงในข้อความตอบกลับใหม่ (หากแปลงข้อความ request จาก XML เป็น JSON ก็เพียงตั้งค่าทั้ง 2 ค่าเป็น request
)
เนื่องจากคุณต้องการแปลงการตอบกลับจาก XML เป็น JSON คุณจึงต้องกำหนดค่าขั้นตอนการตอบกลับแบบมีเงื่อนไขเพื่อทำการแปลง เช่น หากต้องการแปลงการตอบกลับทั้งหมดจาก XML เป็น JSON ก่อนจะส่งกลับไปยังแอปไคลเอ็นต์ ให้กำหนดค่าโฟลว์การตอบสนอง ProxyEndpoint ต่อไปนี้
<Flows> <Flow name="Convert-for-devices"> <Response> <Step><Name>ConvertToJSON</Name></Step> </Response> </Flow> </Flows>
เมื่อเรียกใช้ API โดยใช้คำขอมาตรฐาน การตอบกลับจะอยู่ในรูปแบบ JSON
อย่างไรก็ตาม เป้าหมายของคุณคือการแปลงรายงานสภาพอากาศเป็น JSON เท่านั้น เมื่อไคลเอ็นต์ที่ส่งคำขอเป็นอุปกรณ์เคลื่อนที่ หากต้องการเปิดใช้ลักษณะการทำงานแบบไดนามิกดังกล่าว คุณต้องเพิ่มคำสั่งแบบมีเงื่อนไขลงในโฟลว์
ทดสอบโฟลว์แบบมีเงื่อนไข
ในคำขอตัวอย่างนี้ ส่วนหัว HTTP User-Agent
มีการตั้งค่าเป็น Mozilla
ซึ่งทำให้คำสั่งแบบมีเงื่อนไขประเมินเป็น "จริง" และโฟลว์แบบมีเงื่อนไข Convert-for-devices
ทำงาน
$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
หรือหากต้องการพิมพ์ให้สวยในพื้นที่ที่มี Python ให้บริการ:
$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282 | python -mjson.tool
ตัวอย่างคำตอบ:
. . . "yweather_forecast": [ { "code": "11", "date": "12 Dec 2012", "day": "Wed", "high": "55", "low": "36", "text": "Showers" }, { "code": "32", "date": "13 Dec 2012", "day": "Thu", "high": "56", "low": "38", "text": "Sunny" } ] } . . .
คำขอที่ส่งโดยไม่มีส่วนหัว User-Agent
หรือมีค่าอื่นที่ไม่ใช่ Mozilla
จะทำให้ได้รับการตอบกลับในรูปแบบ XML
$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
การตอบกลับ XML ที่ไม่มีการแก้ไขจะปรากฏขึ้น
ตัวอย่างคำตอบ:
<yweather:forecast day="Wed" date="12 Dec 2012" low="36" high="55" text="Showers" code="11" /> <yweather:forecast day="Thu" date="13 Dec 2012" low="38" high="56" text="Sunny" code="32" />
การจับคู่รูปแบบ
ส่วนนี้จะอธิบายวิธีใช้การจับคู่รูปแบบกับเงื่อนไขในขั้นตอนของ Apigee
โอเปอเรเตอร์
ส่วนนี้จะอธิบายวิธีใช้โอเปอเรเตอร์การจับคู่รูปแบบต่อไปนี้ในคำสั่งแบบมีเงื่อนไข
- ตรงกับโอเปอเรเตอร์: การจับคู่รูปแบบอย่างง่าย
- โอเปอเรเตอร์ JavaRegex: ควบคุมการจับคู่ได้มากขึ้น
- โอเปอเรเตอร์ MatchesPath: การจับคู่ส่วนย่อยเส้นทาง
ตรงกับ
ลองดูโอเปอเรเตอร์แบบมีเงื่อนไข "ตรงกัน" หรือ "~" ก่อน โอเปอเรเตอร์ทั้ง 2 ตัวนี้เหมือนกัน กล่าวคือในเวอร์ชันภาษาอังกฤษ "การจับคู่" ซึ่งเป็นตัวเลือกที่อ่านง่ายกว่า
สรุป: โอเปอเรเตอร์ "รายการที่ตรงกัน" จะให้ผล 2 ประการดังนี้ จับคู่สตริงโดยตรงหรือใช้ไวลด์การ์ดจับคู่กับ "*" ทั้งนี้ไวลด์การ์ดจะจับคู่อักขระ 0 ตัวขึ้นไป มาดูวิธีการทำงานกัน
XML ต่อไปนี้จะแสดงเงื่อนไข "ขั้นตอน" เรียกใช้นโยบาย SomePolicy เมื่อประเมินเงื่อนไขเป็น "จริง" ในตัวอย่างนี้ เราทดสอบตัวแปร proxy.pathsuffix
ซึ่งเป็นตัวแปรบิวท์อินใน Edge ที่เก็บคำต่อท้ายเส้นทางของคำขอ อย่างไรก็ตาม โปรดทราบว่าคุณทดสอบค่าของตัวแปรโฟลว์ทั้งหมดที่มีสตริงได้ ดังนั้นในกรณีนี้ หากเส้นทางพื้นฐานของคำขอขาเข้าคือ /animals
และคำขอคือ /animals/cat
คำต่อท้ายเส้นทางจะเป็นสตริง "/cat
" ตามตัวอักษร
<PreFlow name="PreFlow"> <Request> <Step> <Condition>(proxy.pathsuffix Matches "/cat")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดจะทำให้ SomePolicy ทำงาน ซึ่งทำได้เพียงอย่างใดอย่างหนึ่งเท่านั้น
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ใช่ เนื่องจากคำต่อท้ายเส้นทางพร็อกซีตรงกับ "/cat
" ทุกประการ และจะไม่ดําเนินการใดๆ หากคําต่อท้ายคือ /bat
หรือ /dog
หรือ "/
" หรือสิ่งอื่นใด
ลองนึกถึงข้อความแบบมีเงื่อนไขนี้ที่เราใช้อักขระไวลด์การ์ด "*
"
<Condition>(proxy.pathsuffix Matches "/*at")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ใช่ เนื่องจากไวลด์การ์ดตรงกับอักขระใดก็ได้ และ "/cat
" ตรงกัน
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/bat
นโยบายทํางานหรือไม่ ใช่ เนื่องจากไวลด์การ์ดจับคู่กับอักขระใดก็ได้ ดังนั้น "/bat"
จึงตรงกัน
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/owl
นโยบายทํางานหรือไม่ ไม่ใช่แน่นอน แม้ว่าไวลด์การ์ดจะตรงกับ "o
" แต่ตัวอักษร "wl
" กลับไม่ตรง
ต่อไปให้ย้ายสัญลักษณ์แทนไปที่ส่วนท้ายของส่วนต่อท้าย
<Condition>(proxy.pathsuffix Matches "/cat*")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ใช่ เนื่องจากไวลด์การ์ดจับคู่กับอักขระ 0 ตัวขึ้นไป
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/bat
นโยบายทํางานหรือไม่ ไม่ "/bat
" ไม่ตรงกัน
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat123
นโยบายทํางานหรือไม่ ใช่ ไวลด์การ์ดจะจับคู่อักขระตั้งแต่ 0 ตัวขึ้นไป ดังนั้น "123
" จะแสดงผลการจับคู่
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat/bird/mouse
นโยบายทํางานหรือไม่ ใช่ เนื่องจากไวลด์การ์ดจะจับคู่อักขระตั้งแต่ 0 ตัวขึ้นไป "/bird/mouse
" จึงมีการจับคู่ โปรดสังเกตว่าการแสดงออกแบบนี้จะทำให้คุณมีปัญหาได้อย่างไร เพราะนิพจน์นี้จะจับคู่ทุกอย่างที่อยู่หลังอักขระตามตัวอักษร
คำถาม: ตัวดำเนินการจับคู่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หรือไม่
ได้ สมมติว่าคุณมีเงื่อนไขต่อไปนี้
<Condition>(proxy.pathsuffix Matches "/*At")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ไม่ ไวลด์การ์ดจะจับคู่ตัวอักษรใดก็ได้ (โดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่) แต่ตัวพิมพ์เล็ก "a" ไม่ตรงกับ "A"
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/bAt
นโยบายทํางานหรือไม่ ใช่ กรณีนี้ตรง
คำถาม: ฉันจะหลีกอักขระด้วยโอเปอเรเตอร์ "การจับคู่" ได้อย่างไร
ใช้อักขระเปอร์เซ็นต์ "%" เพื่อหลีกอักขระที่สงวนไว้ เช่น
<Condition>(proxy.pathsuffix Matches "/c%*at")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ไม่ โอเปอเรเตอร์การจับคู่กำลังค้นหาสตริง "c*at" ตรงตัวจริง
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/c*at
คำถาม:นโยบายทํางานหรือไม่
ใช่ เส้นทางนี้จับคู่กันแม้จะแปลกๆ เล็กน้อย
JavaRegex
จะเห็นได้ว่าโอเปอเรเตอร์ "การจับคู่ที่ตรงกัน" เหมาะสำหรับสถานการณ์ทั่วไป แต่คุณใช้โอเปอเรเตอร์อื่น ซึ่งก็คือโอเปอเรเตอร์ "JavaRegex" หรือ "~~" ได้ 2 รายการนี้เป็นโอเปอเรเตอร์เดียวกัน ยกเว้น JavaRegex จะถือว่าอ่านได้มากกว่า โดยมีชื่อว่า JavaRegex เพราะใช้การจับคู่รูปแบบนิพจน์ทั่วไปได้และ Edge จะใช้กฎเดียวกันกับคลาสในแพ็กเกจ java.util.regex ในภาษา Java วิธีการทํางานของโอเปอเรเตอร์ JavaRegex แตกต่างจากโอเปอเรเตอร์ "การจับคู่" เป็นอย่างมาก ดังนั้นจึงไม่ควรสับสนระหว่างทั้ง 2 รายการนี้
สรุป: โอเปอเรเตอร์ "JavaRegex" ช่วยให้คุณใช้ไวยากรณ์นิพจน์ทั่วไปในคำสั่งแบบมีเงื่อนไขได้
โค้ดต่อไปนี้แสดงเงื่อนไข "ขั้นตอน" เรียกใช้นโยบาย SomePolicy หากเงื่อนไขมีค่าเป็น "จริง" ในตัวอย่างนี้ เราทดสอบตัวแปร proxy.pathsuffix
ซึ่งเป็นตัวแปรบิวท์อินใน Edge ที่เก็บคำต่อท้ายเส้นทางของคำขอ หากเส้นทางฐานของคำขอที่เข้ามาใหม่คือ /animals
และคำขอคือ /animals/cat
คำต่อท้ายเส้นทางจะเป็นสตริง "/cat
" ตรงตัว
<PreFlow name="PreFlow"> <Request> <Step> <Condition>(proxy.pathsuffix JavaRegex "/cat")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดจะทำให้ SomePolicy ทำงาน ในกรณีนี้มีเพียงโอเปอเรเตอร์เดียวที่เป็นไปได้เช่นเดียวกับโอเปอเรเตอร์การจับคู่
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ใช่ เนื่องจากคำต่อท้ายเส้นทางพร็อกซีตรงกับ "/cat
" ทุกประการ และจะไม่ดําเนินการใดๆ หากคําต่อท้ายคือ /bat
หรือ /dog
หรืออื่นๆ
ต่อไป เราจะมาสร้างนิพจน์ทั่วไปโดยใช้ตัวระบุ "*" ตัวระบุนี้ตรงกับอักขระที่นำหน้า 0 ตัวขึ้นไป
<Condition>(proxy.pathsuffix JavaRegex "/c*t")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ไม่เอาด้วยหรอก ตัวขยาย "*" ตรงกับอักขระ ก่อนหน้า 0 ตัวขึ้นไป ซึ่งก็คือ "c
"
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/ccccct
นโยบายทํางานหรือไม่ ใช่ เนื่องจากไวลด์การ์ดตรงกับอักขระที่นำหน้า 0 ตัวขึ้นไป
ถัดไป เราใช้ตัวระบุ "?
" ซึ่งตรงกับอักขระนำหน้า 1 ครั้ง หรือไม่จับคู่เลย
<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ได้ ตัวขยาย "?
" จะจับคู่กับอักขระก่อนหน้า 0 หรือ 1 ตัวซึ่งเป็น "a
"
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/ct
นโยบายทํางานหรือไม่ ได้ ตัวขยาย "?
" ตรงกับอักขระก่อนหน้า 1 ตัวหรือไม่เลย ในกรณีนี้ ไม่มีอักขระ "a" ดังนั้นเงื่อนไขจะประเมินค่าเป็นจริง
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/caat
นโยบายทํางานหรือไม่ ไม่ ตัวขยาย "?" ตรงกับอักขระ 1 ตัวที่นำหน้าซึ่งเป็น "a
"
ต่อไป เราใช้รูปแบบ "[abc]
" หรือ "การจัดกลุ่ม" ของนิพจน์นิพจน์ทั่วไป ซึ่งตรงกับอักขระ "a
" หรือ "b
" หรือ "c
"
<Condition>(proxy.pathsuffix JavaRegex "/[cbr]at")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ได้ เราใช้นิพจน์ทั่วไปที่นี่ และนิพจน์ "[cbr]
" ตรงกับ "c", "b", OR "r" การโทรเหล่านี้ยังตรงกับ
GET http://artomatic-test.apigee.net/matchtest/bat
GET http://artomatic-test.apigee.net/matchtest/rat
แต่ข้อมูลนี้ไม่ตรงกัน
GET http://artomatic-test.apigee.net/matchtest/mat
คำถาม: โอเปอเรเตอร์ JavaRegex พิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หรือไม่
ได้ สมมติว่าคุณมีเงื่อนไขต่อไปนี้
<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
นโยบายทํางานหรือไม่ ใช่ regex จะจับคู่ 0 หรืออักขระข้างหน้า 1 ตัว ซึ่งก็คือ "a"
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cAt
คำถาม: นโยบายทํางานหรือไม่
ไม่ เนื่องจากอักษรตัวพิมพ์ใหญ่ "A" ไม่ตรงกับตัวอักษรพิมพ์เล็ก "a"
MatchesPath
คุณยังระบุโอเปอเรเตอร์ MatchesPath
แบบนี้ "~/" ได้ด้วย ซึ่งมีลักษณะคล้ายกับโอเปอเรเตอร์ Matches
(~) และ JavaRegex (~~) แต่ MatchesPath นั้นต่างออกไปโดยสิ้นเชิง
โปรดทราบว่าโอเปอเรเตอร์นี้จะดูเส้นทางเป็นชุดชิ้นส่วน ดังนั้น หากเส้นทางคือ /animals/cats/wild
ก็ให้คิดว่าเส้นทางนั้นประกอบด้วยส่วน "/animals
" "/cats
" และ "/wild
"
โอเปอเรเตอร์ MatchesPath
ให้คุณใช้สัญลักษณ์ไวลด์การ์ดได้ 2 แบบ ได้แก่ เครื่องหมายดอกจัน (*) 1 อันและเครื่องหมายดอกจัน 2 ตัว (**) เครื่องหมายดอกจันเดี่ยวจะตรงกับองค์ประกอบเส้นทาง 1 องค์ประกอบ โดยเครื่องหมายดอกจันคู่จะตรงกับองค์ประกอบเส้นทางอย่างน้อย 1 รายการ
ยกตัวอย่างเช่น ในตัวอย่างนี้ เราทดสอบตัวแปร proxy.pathsuffix
ซึ่งเป็นตัวแปรบิวท์อินใน Edge ที่เก็บคำต่อท้ายเส้นทางของคำขอ อย่างไรก็ตาม โปรดทราบว่าคุณทดสอบค่าของตัวแปรโฟลว์ทั้งหมดที่มีสตริงได้
<PreFlow name="PreFlow"> <Request> <Step> <Condition>(proxy.pathsuffix MatchesPath "/animals/*")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดจะทำให้ SomePolicy ทำงาน
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/animals
คำถาม: นโยบายทํางานหรือไม่
ไม่ได้ เนื่องจากเงื่อนไขต้องมีองค์ประกอบเส้นทางอื่นหลัง "/animals
" ตามที่ระบุโดย "/*
"
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/animals
/
นโยบายทํางานหรือไม่ ใช่ เส้นทางมีองค์ประกอบอื่นของเส้นทาง (ส่วนที่อยู่หลัง "/animals/
") แต่องค์ประกอบว่างเปล่า
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/animals/cats
นโยบายทํางานหรือไม่ ใช่ เนื่องจากเส้นทางมีองค์ประกอบ ("/cats
") ที่อยู่หลัง "/animals
" อย่างชัดเจน
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild
คำถาม: นโยบายทํางานหรือไม่
ไม่ เนื่องจากเครื่องหมายดอกจันตัวเดียวตรงกับองค์ประกอบของเส้นทางเพียง 1 องค์ประกอบ และ API นี้มีองค์ประกอบมากกว่า 1 รายการที่อยู่หลัง "/animals
"
ต่อไป เราจะใช้เครื่องหมายดอกจัน 2 ตัว ดังนี้
<PreFlow name="PreFlow"> <Request> <Step> <Condition>(proxy.pathsuffix MatchesPath "/animals/**")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดจะทำให้ SomePolicy ทำงาน
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/animals
นโยบายทํางานหรือไม่ ไม่ เนื่องจากเงื่อนไขต้องมีองค์ประกอบเส้นทางต่อไปนี้อย่างน้อย 1 รายการที่ระบุโดย "/**
"
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/animals
/
นโยบายทํางานหรือไม่
ใช่ เส้นทางมีองค์ประกอบอื่นของเส้นทาง (ส่วนที่อยู่หลัง "/animals/
") แต่องค์ประกอบว่างเปล่า
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/animals/cats
นโยบายทํางานหรือไม่
ใช่ เนื่องจากเส้นทางมีองค์ประกอบอย่างน้อย 1 รายการที่ตามหลัง "/animals
"
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild
นโยบายทํางานหรือไม่
ใช่ เนื่องจากเส้นทางมีองค์ประกอบมากกว่า 1 รายการที่ตามหลัง "/animals
"
เครื่องหมายดอกจันผสม
คุณสามารถใช้การผสมระหว่างเครื่องหมายดอกจัน (*) เดี่ยว (*) และคู่ (**) เพื่อปรับแต่งการจับคู่เส้นทางเพิ่มเติมได้
<PreFlow name="PreFlow"> <Request> <Step> <Condition>(proxy.pathsuffix MatchesPath "/animals/*/wild/**")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
การเรียก API
การเรียก API เหล่านี้ทั้งหมดจะทำให้เกิดการจับคู่:
GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild/
และ
GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian
และ
GET
http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches
ทรัพยากร API
บริการ RESTful คือคอลเล็กชันของทรัพยากร API ทรัพยากร API คือส่วนย่อยของเส้นทาง URI ที่ระบุเอนทิตีบางอย่างที่นักพัฒนาซอฟต์แวร์เข้าถึงได้ด้วยการเรียก API ของคุณ ตัวอย่างเช่น หากบริการของคุณมีรายงานสภาพอากาศและพยากรณ์อากาศ บริการแบ็กเอนด์อาจกำหนดทรัพยากร API 2 รายการดังนี้
- http://mygreatweatherforecast.com/reports
- http://mygreatweatherforecast.com/forecasts
เมื่อสร้างพร็อกซี API (ดังที่แสดงในสร้างพร็อกซี API แรกของคุณ) อย่างน้อยจะเป็นการสร้าง URL ฐานของชื่อแทนที่แมปกับบริการแบ็กเอนด์ เช่น
URL ฐานของแบ็กเอนด์ | URL พร็อกซี API ใหม่/ที่เทียบเท่า |
---|---|
http://mygreatweatherforecast.com | http://{your_org}-{environment}.apigee.net/mygreatweatherforecast |
ในจุดนี้คุณจะเรียก API ไปยังแบ็กเอนด์ได้โดยใช้ URL ฐานรายการใดรายการหนึ่ง แต่เมื่อคุณใช้ URL พร็อกซี API สิ่งต่างๆ ก็เริ่มน่าสนใจขึ้น
นอกเหนือจากการวิเคราะห์ API ที่ Edge เริ่มรวบรวมเมื่อคุณใช้พร็อกซี API แล้ว พร็อกซียังช่วยให้คุณกำหนดโฟลว์แบบมีเงื่อนไขที่แมปกับทรัพยากรบนแบ็กเอนด์ด้วย โดยมีสาระสำคัญคือ "ถ้ามีการเรียก GET ไปยังทรัพยากร /reports เขาควรดำเนินการบางอย่าง"
รูปภาพต่อไปนี้แสดงความแตกต่างของลักษณะการทำงานระหว่าง URL 2 รายการที่เข้าถึงแบ็กเอนด์เดียวกันในท้ายที่สุด รายการแรกคือ URL ทรัพยากรที่ไม่ใช่พร็อกซี ส่วนอีกรายการเป็นพร็อกซี Edge API ที่มีโฟลว์แบบมีเงื่อนไขไปยังทรัพยากรแบ็กเอนด์เดียวกัน เราจะอธิบายขั้นตอนแบบมีเงื่อนไขอย่างละเอียดด้านล่าง
วิธีที่พร็อกซี API แมปกับทรัพยากรแบ็กเอนด์ที่เจาะจง
เมื่อใช้ URL พร็อกซี API ที่แมปกับ URL หลักของบริการแบ็กเอนด์ (เมื่อสร้างพร็อกซี) คุณจะเพิ่มโฟลว์แบบมีเงื่อนไขลงในทรัพยากรที่เจาะจงได้ เช่น ทรัพยากร /reports
และ /forecasts
ที่กล่าวถึงไปก่อนหน้านี้
สมมติว่าคุณต้องการให้ Edge "ทำอะไรสักอย่าง" เมื่อมีสายเรียกเข้าไปที่ทรัพยากรของ /reports
หรือ /forecasts
ณ จุดนี้ที่คุณไม่ได้บอก Edge ว่าต้องทำอะไร แต่ควรฟังเสียงที่เรียกไปยังทรัพยากรเหล่านั้น คุณจะดำเนินการนี้แบบมีเงื่อนไข ในพร็อกซี Edge API คุณสร้างโฟลว์แบบมีเงื่อนไขสำหรับ /reports
และ /forecasts
ได้ XML ของพร็อกซี API ต่อไปนี้จะแสดงลักษณะของเงื่อนไขเหล่านั้นเพื่อวัตถุประสงค์ทางแนวคิด
<Flows> <Flow name="reports"> <Description/> <Request/> <Response/> <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition> </Flow> <Flow name="forecasts"> <Description/> <Request/> <Response/> <Condition>(proxy.pathsuffix MatchesPath "/forecasts") and (request.verb = "GET")</Condition> </Flow> </Flows>
เงื่อนไขดังกล่าวระบุว่า "เมื่อมีคำขอ GET มาพร้อมกับ /reports
และ /forecasts
ใน URL แล้ว Edge จะทำทุกวิถีทางที่คุณ (นักพัฒนาซอฟต์แวร์ API) บอก ผ่านนโยบายที่คุณแนบไว้กับขั้นตอนเหล่านั้น
ตัวอย่างการบอกให้ Edge รู้ว่าต้องทำอะไรบ้างเมื่อตรงตามเงื่อนไข ใน XML ของพร็อกซี API ต่อไปนี้ เมื่อส่งคำขอ GET ไปยัง https://yourorg-test.apigee.net/mygreatweatherforecast/reports
Edge จะดำเนินการตามนโยบาย "XML-to-JSON-1" ในการตอบกลับ
<Flows> <Flow name="reports"> <Description/> <Request/> <Response> <Step> <Name>XML-to-JSON-1</Name> </Step> </Response> <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition> </Flow>
นอกเหนือจากโฟลว์แบบมีเงื่อนไขที่เป็นตัวเลือกแล้ว พร็อกซี API แต่ละรายการยังมีโฟลว์เริ่มต้น 2 โฟลว์ ได้แก่ <PreFlow>
ที่ดำเนินการก่อนโฟลว์แบบมีเงื่อนไข และ <PostFlow>
ที่ดำเนินการหลังจากโฟลว์แบบมีเงื่อนไข วิธีนี้มีประโยชน์สำหรับการบังคับใช้นโยบายเมื่อมีการเรียกใดๆ ไปยังพร็อกซี API เช่น หากต้องการยืนยันคีย์ API ของแอปที่มีการเรียกทุกๆ ครั้ง ไม่ว่าจะมีการเข้าถึงทรัพยากรแบ็กเอนด์ใดก็ตาม คุณจะวางนโยบายคีย์ API ยืนยันใน <PreFlow>
ได้ ดูข้อมูลเพิ่มเติมเกี่ยวกับขั้นตอนได้ที่การกำหนดค่าขั้นตอน
สร้างโฟลว์แบบมีเงื่อนไขไปยังทรัพยากรแบ็กเอนด์
การกำหนดโฟลว์แบบมีเงื่อนไขให้กับทรัพยากรแบ็กเอนด์ในพร็อกซี API นั้นทำหรือไม่ก็ได้ อย่างไรก็ตาม ขั้นตอนแบบมีเงื่อนไขเหล่านั้นช่วยให้คุณใช้การจัดการและการตรวจสอบแบบละเอียดได้
โดยคุณจะดำเนินการต่อไปนี้ได้
- ใช้การจัดการในลักษณะที่สะท้อนอรรถศาสตร์ของโมเดล API ของคุณ
- ใช้นโยบายและลักษณะการทำงานที่ใช้สคริปต์กับเส้นทางทรัพยากร (URI) แต่ละเส้นทาง
- รวบรวมเมตริกแบบละเอียดสำหรับบริการ Analytics
ตัวอย่างเช่น สมมติว่าคุณต้องใช้ตรรกะประเภทต่างๆ กับทรัพยากร /apps ของแบ็กเอนด์กับ /developers
ในการดำเนินการดังกล่าว ให้เพิ่มโฟลว์แบบมีเงื่อนไข 2 รายการในพร็อกซี API ได้แก่ /developers
และ /apps
ในมุมมองพัฒนาของแผงการนำทางของเครื่องมือแก้ไขพร็อกซี API ให้คลิกไอคอน + ถัดจากค่าเริ่มต้นในปลายทางของพร็อกซี
ในหน้าต่าง "โฟลว์ตามเงื่อนไขใหม่" ให้ป้อนการกําหนดค่าคีย์ต่อไปนี้
- ชื่อโฟลว์: นักพัฒนาซอฟต์แวร์
- ประเภทเงื่อนไข: เส้นทาง
- เส้นทาง: /developers
ระบบจะทริกเกอร์เงื่อนไข (และจะดำเนินนโยบาย) หากมีการส่งการเรียกไปยังพร็อกซีโดยมี /developers อยู่ที่ส่วนท้ายของ URI
ตอนนี้ให้เพิ่มขั้นตอนแบบมีเงื่อนไขสำหรับ /apps และสมมติว่าคุณต้องการให้ทริกเกอร์เงื่อนไขทั้งใน URI และคำกริยา POST ในคำขอ การกำหนดค่าต้องมีการตั้งค่าต่อไปนี้
- ชื่อโฟลว์: แอป
- ประเภทเงื่อนไข: เส้นทางและคำกริยา
- เส้นทาง: /apps
- กริยา: โพสต์
ระบบจะทริกเกอร์เงื่อนไข (และจะดำเนินนโยบาย) ถ้ามีการส่งการเรียกไปยังพร็อกซีโดยมี /apps ต่อท้าย URI และมีคำกริยา POST
ในแผงการนำทาง คุณจะเห็นขั้นตอนใหม่สำหรับแอปและนักพัฒนาซอฟต์แวร์
เลือกขั้นตอนใดขั้นตอนหนึ่งเพื่อดูการกำหนดค่าโฟลว์แบบมีเงื่อนไขในมุมมองโค้ดของตัวแก้ไขพร็อกซี API
<Flow name="Apps"> <Description>Developer apps registered in Developer Services</Description> <Request/> <Response/> <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition> </Flow>
จะเห็นได้ว่าทรัพยากร API เป็นเพียงโฟลว์แบบมีเงื่อนไขที่ประเมินเส้นทาง URI ของคำขอขาเข้า (ตัวแปรproxy.pathsuffix ระบุ URI ของคำขอที่ตามหลัง BasePath ที่กําหนดค่าไว้ในการกําหนดค่า ProxyEndpoint)
ทรัพยากร API แต่ละรายการที่คุณกำหนดจะใช้งานโดยโฟลว์แบบมีเงื่อนไขในพร็อกซี API (ดูการกำหนดค่าโฟลว์)
เมื่อคุณทำให้พร็อกซี API ใช้งานได้กับสภาพแวดล้อมการทดสอบ คำขอต่อไปนี้
http://{org_name}-test.apigee.net/{proxy_path}/apps
จะทำให้เงื่อนไขประเมินค่าเป็น "จริง" ระบบจะดำเนินการขั้นตอนนี้พร้อมนโยบายที่เกี่ยวข้อง
เงื่อนไขตัวอย่างต่อไปนี้ใช้นิพจน์ทั่วไปของ Java เพื่อจดจำการเรียกไปยังทรัพยากร /apps
ที่มีหรือไม่มีเครื่องหมายทับปิดท้าย (/apps
หรือ /apps/**
)
<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับเงื่อนไขประเภทนี้ที่วิธีจับคู่โดยไม่สนใจ ... ในชุมชน Apigee
การสร้างโมเดล URI แบบลำดับชั้น
ในบางกรณี คุณจะมีทรัพยากร API แบบลำดับชั้น เช่น Developer Services API มีวิธีแสดงแอปทั้งหมดที่เป็นของนักพัฒนาซอฟต์แวร์ เส้นทาง URI คือ
/developers/{developer_email}/apps
คุณอาจมีทรัพยากรที่สร้างรหัสที่ไม่ซ้ำกันสำหรับเอนทิตีแต่ละรายการในคอลเล็กชัน ซึ่งบางครั้งอาจมีคำอธิบายประกอบดังนี้
/genus/:id/species
เส้นทางนี้ใช้กับ URI ทั้งสองต่อไปนี้เท่าๆ กัน:
/genus/18904/species /genus/17908/species
คุณใช้ไวลด์การ์ดเพื่อแสดงโครงสร้างนี้ในทรัพยากร API ได้ เช่น
/developers/*/apps
/developers/*example.com/apps
/genus/*/species
จะแปล URI แบบลำดับชั้นเหล่านี้เป็นทรัพยากร API อย่างเหมาะสม
ในบางกรณี โดยเฉพาะสำหรับ API ที่มีลำดับชั้นบางขั้น คุณอาจต้องการแก้ไขทุกอย่างที่อยู่ใต้ส่วนย่อย URI บางรายการ ในการดำเนินการ ให้ใช้ไวลด์การ์ดที่มีเครื่องหมายดอกจัน 2 ตัวในคำจำกัดความทรัพยากร เช่น หากคุณกำหนดทรัพยากร API ต่อไปนี้/developers/**
ทรัพยากร API ดังกล่าวจะแก้ไขเส้นทาง URI ต่อไปนี้
/developers/{developer_email}/apps /developers/{developer_email}/keys /developers/{developer_email}/apps/{app_id}/keys
เงื่อนไขของโฟลว์แบบมีเงื่อนไขในคำจำกัดความของพร็อกซี API มีดังนี้
<Condition>(proxy.pathsuffix MatchesPath "/developers/**") and (request.verb = "POST")</Condition>
ตัวอย่างอื่นๆ
แนบเงื่อนไขกับ RouteRule แล้ว
<RouteRule name="default">
<!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
<Condition>request.header.content-type = "text/xml"</Condition>
<TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>
แนบเงื่อนไขกับนโยบายแล้ว
<Step> <!--the policy MaintenancePolicy only executes if the response status code is exactly 503--> <Condition>response.status.code = 503</Condition> <Name>MaintenancePolicy</Name> </Step>
โฟลว์แบบมีเงื่อนไข
<!-- this entire flow is executed only if the request verb is a GET--> <Flow name="GetRequests"> <Condition>request.verb="GET"</Condition> <Request> <Step> <!-- this policy only executes if request path includes a term like statues--> <Condition>request.path ~ "/statuses/**"</Condition> <Name>StatusesRequestPolicy</Name> </Step> </Request> <Response> <Step> <!-- this condition has multiple expressions. The policy executes if the response code status is exactly 503 or 400--> <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition> <Name>MaintenancePolicy</Name> </Step> </Response> </Flow>
โอเปอเรเตอร์ตัวอย่างในเงื่อนไข
ตัวอย่างโอเปอเรเตอร์ที่ใช้สร้างเงื่อนไขมีดังนี้
request.header.content-type = "text/xml"
request.header.content-length < 4096 && request.verb = "PUT"
response.status.code = 404 || response.status.code = 500
request.uri MatchesPath "/*/statuses/**"
request.queryparam.q0 NotEquals 10
ตัวอย่างที่ใช้ได้จริง: ละเว้น "/" ที่ส่วนท้ายของเส้นทาง
นักพัฒนาซอฟต์แวร์ Edge มักต้องการจัดการคำต่อท้ายเส้นทางทั้ง 2 แบบ ได้แก่ "/cat
" และ "/cat/
" เนื่องจากผู้ใช้บางรายหรือไคลเอ็นต์บางรายอาจเรียกใช้ API ของคุณด้วยเครื่องหมายทับเพิ่มเติมในส่วนท้ายของเส้นทาง และคุณต้องจัดการเรื่องดังกล่าวได้ในคำสั่งแบบมีเงื่อนไข กรณีการใช้งานที่แน่นอนนี้
มีการพูดคุยกันในชุมชน Apigee
หากต้องการ คุณสามารถบรรลุเป้าหมายนี้โดยไม่ต้องใช้นิพจน์ทั่วไป
<PreFlow name="PreFlow"> <Request> <Step> <Condition>((proxy.pathsuffix = "/cat") OR (proxy.pathsuffix = "/cat/")</Condition> <Name>SomePolicy</Name> </Step> </Request> <Response/> </PreFlow>
ซึ่งถือเป็นตัวเลือกที่ดี ชัดเจนและอ่านออก
คุณทำแบบเดียวกันด้วยนิพจน์ทั่วไปได้ แต่แบบนี้ วงเล็บใช้ในการจัดกลุ่มส่วนนิพจน์ทั่วไปของคำสั่ง แต่ไม่จำเป็น
<Condition>(proxy.pathsuffix JavaRegex "/cat(/?)"</Condition>
การเรียก API
GET http://artomatic-test.apigee.net/matchtest/cat
or
GET http://artomatic-test.apigee.net/matchtest/cat
/
นโยบายทํางานหรือไม่ ได้ โปรดทราบว่าในนิพจน์ทั่วไป อักขระ "?
" หมายถึงตรงกับอักขระ 0 หรือตัวใดตัวหนึ่งที่อยู่ก่อนหน้า ดังนั้น ทั้ง "/cat
" และ "/cat/
" จะถือว่าตรงกัน
การเรียก API:
GET http://artomatic-test.apigee.net/matchtest/cat/spotted
นโยบายทํางานหรือไม่ ไม่ นิพจน์ทั่วไปจะจับคู่ 0 หรือเพียง 1 รายการของอักขระที่อยู่ก่อนหน้า และจะไม่มีการอนุญาตอื่นๆ อีก
การจับคู่สตริงที่กำหนดเองกับ JavaRegex
ในตัวอย่างทั้งหมดในหัวข้อนี้ เราจะแสดงวิธีจับคู่ตัวแปรโฟลว์บิวท์อินตัวใดตัวหนึ่ง ซึ่งก็คือพร็อกซี.pathsuffix คุณควรทราบว่าคุณสามารถใช้การจับคู่รูปแบบกับสตริงหรือตัวแปรโฟลว์ที่กำหนดเองใดก็ได้ ไม่ว่าจะเป็นตัวแปรโฟลว์ในตัว เช่นproxy.pathsuffix หรือไม่ก็ตาม
ตัวอย่างเช่น หากคุณมีเงื่อนไขที่ทดสอบสตริงที่กำหนดเอง อาจเป็นสตริงที่แสดงผลในเพย์โหลดแบ็กเอนด์ หรือสตริงที่แสดงผลจากการค้นหาเซิร์ฟเวอร์การตรวจสอบสิทธิ์ คุณจะใช้โอเปอเรเตอร์ที่ตรงกันเพื่อทดสอบได้ หากคุณใช้ JavaRegex ระบบจะเปรียบเทียบนิพจน์ทั่วไปกับทั้งสตริงเรื่อง หากหัวเรื่องคือ "abc" และนิพจน์ทั่วไปคือ "[a-z]" จะไม่มีการจับคู่เนื่องจาก "[a-z]" ตรงกับอักขระอัลฟ่า 1 ตัวทุกประการ นิพจน์ "[a-z]+" ใช้งานได้เช่นเดียวกับ "[a-z]*" และ "[a-z]{3}
มาดูตัวอย่างที่เป็นรูปธรรมกัน สมมติว่าเซิร์ฟเวอร์การตรวจสอบสิทธิ์แสดงรายการบทบาทเป็นสตริงที่มีการระบุคอมมา: "เอดิเตอร์, author, guest"
หากต้องการทดสอบการแสดงบทบาทผู้แก้ไข โครงสร้างนี้จะใช้งานไม่ได้ เนื่องจาก "ผู้แก้ไข" เป็นเพียงส่วนหนึ่งของสตริงทั้งหมด
<Condition>returned_roles ~~ "editor"</Condition>
อย่างไรก็ตาม การก่อสร้างนี้จะใช้ได้:
<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>
วิธีนี้ใช้ได้ผลเนื่องจากจะพิจารณาช่วงพักคำและส่วนอื่นๆ ของสตริงที่มีคำนำหน้าและคำต่อท้าย .*
ในตัวอย่างนี้ คุณยังสามารถทดสอบ "ตัวแก้ไข" ด้วยโอเปอเรเตอร์ "การจับคู่"
<Condition>returned_roles ~~ "*editor*")</Condition>
อย่างไรก็ตาม ในกรณีที่คุณต้องการความแม่นยํามากขึ้น JavaRegex ก็มักเป็นตัวเลือกที่ดีกว่า
การใช้อักขระหลีกกับเครื่องหมายคำพูดคู่ในนิพจน์ JavaRegex
ไวยากรณ์เงื่อนไขต้องมีนิพจน์ JavaRegex รวมอยู่ในเครื่องหมายคำพูดคู่ ดังนั้น หากคุณมีนิพจน์นิพจน์ทั่วไปที่มีเครื่องหมายคำพูดคู่ คุณจะต้องใช้วิธีอื่นในการจับคู่นิพจน์ดังกล่าว คำตอบคือ Unicode ตัวอย่างเช่น สมมติว่าคุณส่งผ่านส่วนหัวที่มีเครื่องหมายคำพูดคู่ดังต่อไปนี้-H 'content-type:multipart/related; type="application/xop+xml"'หากคุณพยายามจับคู่ส่วนหัวนั้นในเงื่อนไขนิพจน์ทั่วไป คุณจะได้รับข้อผิดพลาด "เงื่อนไขไม่ถูกต้อง" เนื่องจากนิพจน์มีเครื่องหมายคำพูดคู่ดังนี้
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"วิธีแก้ไขคือให้แทนที่เครื่องหมายคำพูดคู่ที่ใช้ ASCII ด้วยค่าเทียบเท่า Unicode
\u0022
ตัวอย่างเช่น นิพจน์ต่อไปนี้ถูกต้องและสร้างผลลัพธ์ตามที่คาดหวัง
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"