เงื่อนไขที่มีตัวแปรโฟลว์

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

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

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

กำหนดค่าคำสั่งแบบมีเงื่อนไข

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

<Condition></Condition>

หากต้องการสร้างคำสั่งแบบมีเงื่อนไข ให้เพิ่มโอเปอเรเตอร์แบบมีเงื่อนไขและตัวแปรเพื่อสร้าง โครงสร้างต่อไปนี้

<Condition>{variable.name}{operator}{"value"}</Condition>

โอเปอเรเตอร์แบบมีเงื่อนไขที่รองรับ ได้แก่ = (เท่ากับ), != (ไม่เท่ากัน) และ > (มากกว่า) คุณยังเขียนเงื่อนไขเป็นแบบ ข้อความ: equals, notequals, greaterthan

เมื่อใช้เส้นทาง URI คุณจะใช้ ~/ หรือ MatchesPath ได้ คุณสามารถ จับคู่นิพจน์ทั่วไปของ 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 คำสั่งดังกล่าวจะประเมินว่าเป็น "เท็จ"

หากต้องการเปิดใช้ลักษณะการทำงานแบบไดนามิก ให้แนบ "เงื่อนไข" กับ Flows, Steps และ RouteRules

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

เช่น หากต้องการสร้างโฟลว์ที่จะทำงานเมื่อกริยาคำขอเป็น GET เท่านั้น ให้ทำดังนี้

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
</Flows>

วิธีสร้างขั้นตอนหนึ่งสำหรับ GET และอีกขั้นตอนสำหรับ POST มีดังนี้

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
  <Flow name="ExecuteForPOSTs">
  <Condition>request.verb="POST"</Condition>
  </Flow>
</Flows>

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

<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 เพื่อดูว่าเงื่อนไขประเมินเป็น true

หากเงื่อนไขประเมินเป็น "จริง" กล่าวคือ ค่าของตัวแปร 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 เพียงตั้งค่าทั้ง ค่าเหล่านี้ไปยัง request)

เนื่องจากคุณต้องการแปลงการตอบกลับจาก XML เป็น JSON คุณจึงต้องกำหนดค่า ดำเนินการตามขั้นตอนเพื่อทำให้เกิด Conversion เช่น แปลงการตอบกลับทั้งหมดจาก 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

โอเปอเรเตอร์

ส่วนนี้จะอธิบายวิธีใช้โอเปอเรเตอร์การจับคู่รูปแบบต่อไปนี้ในเงื่อนไข ข้อความ:

ตรงกับ

เรามาดูที่ "การจับคู่ที่ตรงกัน" หรือ "~" แบบมีเงื่อนไขก่อน โอเปอเรเตอร์ 2 ตัวนี้คือ เช่นเดียวกัน -- เวอร์ชันภาษาอังกฤษ "ตรงกับ" ถือเป็นตัวเลือกที่อ่านง่ายขึ้น

สรุป: "รายการที่ตรงกัน" ให้คุณดำเนินการได้ 2 อย่าง จับคู่ สตริงตัวอักษร หรือจับคู่ไวลด์การ์ดด้วย "*" อย่างที่คุณคาดไว้ ไวลด์การ์ดจะจับคู่เป็น 0 อักขระขึ้นไป มาดูวิธีการทำงานกัน

XML ต่อไปนี้จะแสดงเงื่อนไขขั้นตอน เครื่องมือดังกล่าวจะบังคับใช้นโยบาย SomePolicy เมื่อเงื่อนไข ประเมินเป็น true ในตัวอย่างนี้ เราทดสอบตัวแปร 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 หรือ 1 ตัวขึ้นไป ดังนั้น "/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" หรือ "~~" สองตัวนี้เป็นโอเปอเรเตอร์เดียวกัน ยกเว้น JavaRegex อ่านได้ง่ายกว่า วิธีนี้เรียกว่า JavaRegex เนื่องจากช่วยให้สามารถใช้นิพจน์ทั่วไป การจับคู่รูปแบบ และ Edge จะใช้กฎเดียวกันกับคลาสใน java.util.regex แพ็กเกจในภาษา Java วิธีการทำงานของโอเปอเรเตอร์ JavaRegex แตกต่างจาก จะจับคู่โอเปอเรเตอร์ ฉะนั้นอย่าสับสนระหว่างทั้ง 2 โอเปอเรเตอร์

สรุป: "JavaRegex" ให้คุณใช้ไวยากรณ์นิพจน์ทั่วไปใน แบบมีเงื่อนไข

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

นโยบายจะทำงานไหม ไม่เอาด้วยหรอก เครื่องหมาย "*" ตัวระบุค่าตรงกับค่า ก่อนหน้า อักขระ ซึ่งก็คือ "c"

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/ccccct

นโยบายจะทำงานไหม ใช่ เนื่องจากไวลด์การ์ดตรงกับค่านำหน้า 0 หรืออย่างน้อย 1 รายการ อักขระ

ต่อไป เราจะใช้ "?" โอเปอเรเตอร์ ซึ่งตรงกับอักขระที่นำหน้า 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 ตัว และ ดอกจันคู่ (**) เครื่องหมายดอกจันเดียวตรงกับองค์ประกอบของเส้นทาง 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

คำถาม: นโยบายทำงานได้หรือไม่

ไม่ เนื่องจากเครื่องหมายดอกจันดอกเดียวตรงกับองค์ประกอบเส้นทางเพียงองค์ประกอบเดียวเท่านั้น และ API นี้มีมากกว่า 1 องค์ประกอบต่อจาก "/animals"

ต่อไปเราจะใช้เครื่องหมายดอกจันคู่ ดังนี้

    <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 Edge ควรทำบางอย่าง"

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

วิธีแมปพร็อกซี API กับทรัพยากรแบ็กเอนด์ที่เฉพาะเจาะจง

โดยการใช้ URL พร็อกซี API ที่แมปกับ URL พื้นฐานของบริการแบ็กเอนด์ (เมื่อคุณสร้างส่วน พร็อกซี) คุณจะสามารถเพิ่มขั้นตอนแบบมีเงื่อนไขไปยังทรัพยากรที่เฉพาะเจาะจง เช่น /reports และแหล่งข้อมูล /forecasts รายการที่กล่าวถึงก่อนหน้านี้

สมมติว่าคุณต้องการให้ Edge "ทำอะไรบางอย่าง" เมื่อมีสายเรียกเข้าไปยัง ทรัพยากร /reports หรือ /forecasts ตอนนี้คุณไม่ได้บอก Edge สิ่งที่ต้องทำ เพียงแต่ควรคอยฟังการเรียกไปยังทรัพยากรเหล่านั้น คุณทำสิ่งนี้ พร้อมกับเงื่อนไข ในพร็อกซี Edge API คุณสามารถสร้างขั้นตอนแบบมีเงื่อนไขสําหรับ /reports และ /forecasts สำหรับวัตถุประสงค์เชิงแนวคิด API ต่อไปนี้ XML ของพร็อกซีจะแสดงหน้าตาของเงื่อนไขเหล่านั้น

<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 ทราบถึงสิ่งที่ต้องทำเมื่อเป็นไปตามเงื่อนไข ใน API ต่อไปนี้ XML ของพร็อกซี เมื่อมีการส่งคำขอ 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

เช่น สมมติว่าคุณต้องใช้ตรรกะประเภทต่างๆ กับแบ็กเอนด์ /developers กับ /apps ทรัพยากร

ในการดำเนินการดังกล่าว ให้เพิ่มขั้นตอนแบบมีเงื่อนไข 2 ขั้นตอนในพร็อกซี API ได้แก่ /developers และ /apps

ในมุมมอง "พัฒนา" ของแผง Navigator ของเครื่องมือแก้ไขพร็อกซี API ให้คลิกไอคอน + ถัดจากค่าเริ่มต้นในปลายทางของพร็อกซี

ใน "โฟลว์แบบมีเงื่อนไขใหม่" คุณจะต้องป้อนการกำหนดค่าคีย์ต่อไปนี้

  • ชื่อโฟลว์: นักพัฒนาซอฟต์แวร์
  • ประเภทเงื่อนไข: เส้นทาง
  • เส้นทาง: /developers

ระบบจะทริกเกอร์เงื่อนไข (และจะมีการบังคับใช้นโยบาย) หากมีการส่งการเรียกใช้ไปยังพร็อกซี กับ /developers ที่ส่วนท้ายของ URI

ตอนนี้ให้เพิ่มขั้นตอนแบบมีเงื่อนไขสําหรับ /apps และสมมติว่าคุณต้องการให้ระบบเรียกให้แสดงเงื่อนไข ทั้ง URI และคำกริยา POST ในคำขอ การกำหนดค่านี้เกี่ยวข้องกับการตั้งค่า ดังต่อไปนี้:

  • ชื่อโฟลว์: แอป
  • ประเภทเงื่อนไข: เส้นทางและคำกริยา
  • เส้นทาง: /apps
  • กริยา: POST

ระบบจะทริกเกอร์เงื่อนไข (และจะมีการบังคับใช้นโยบาย) หากมีการส่งการเรียกใช้ไปยังพร็อกซี โดยมี /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 ของ คำขอขาเข้า (ตัวแปรพร็อกซี.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 แบบลำดับชั้น เช่น บริการสําหรับนักพัฒนาแอป API มีวิธีการแสดงแอปทั้งหมดที่เป็นของนักพัฒนาแอป เส้นทาง URI คือ

/developers/{developer_email}/apps

คุณอาจมีทรัพยากรที่สร้างรหัสที่ไม่ซ้ำกันสำหรับเอนทิตีแต่ละรายการในคอลเล็กชัน ซึ่ง ในบางครั้งจะมีคำอธิบายประกอบดังต่อไปนี้

/genus/:id/species

เส้นทางนี้นำไปใช้กับ URI 2 รายการต่อไปนี้ได้เท่ากัน

/genus/18904/species
/genus/17908/species

คุณใช้ไวลด์การ์ดเพื่อแสดงโครงสร้างนี้ในทรัพยากร API ได้ เช่น

/developers/*/apps
 
/developers/*example.com/apps
 
/genus/*/species

จะแปลง URI แบบลำดับชั้นเหล่านี้เป็นทรัพยากร API อย่างเหมาะสม

ในบางกรณี โดยเฉพาะอย่างยิ่งสำหรับ API ที่มีลําดับชั้นขั้นสูง คุณอาจต้องการแก้ไขทุกอย่างที่อยู่ใต้ ส่วนย่อยของ URI ที่เฉพาะเจาะจง โดยให้ใช้ไวลด์การ์ดเครื่องหมายดอกจันคู่ในคำจำกัดความทรัพยากร สำหรับ ตัวอย่างเช่น หากคุณกำหนดทรัพยากร 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 หรือ 1 กับอักขระก่อนหน้า ดังนั้น "/cat" และ "/cat/" เป็นรายการที่ตรงกัน

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/cat/spotted

นโยบายจะทำงานไหม ไม่ นิพจน์ทั่วไปตรงกับรายการ 0 หรือมีเพียง 1 รายการของ นำหน้า และไม่อนุญาตให้ใช้อักขระอื่นๆ อีก

การจับคู่สตริงที่กำหนดเองกับ JavaRegex

ในตัวอย่างทั้งหมดในหัวข้อนี้ เราจะแสดงวิธีจับคู่ตัวแปรโฟลว์แบบบิวท์อิน proxy.pathsuffix. การที่คุณสามารถจับคู่รูปแบบกับสตริงที่กำหนดเองใดๆ หรือ โฟลว์ ตัวแปรโฟลว์ ที่เป็นตัวแปรโฟลว์ในตัว เช่น session.pathsuffix หรือไม่

ตัวอย่างเช่น หากคุณมีเงื่อนไขที่ทดสอบสตริงที่กําหนดเอง สตริงที่แสดงขึ้นมา ในเพย์โหลดแบ็กเอนด์ หรือสตริงที่แสดงผลจากการค้นหาเซิร์ฟเวอร์การตรวจสอบสิทธิ์ คุณสามารถใช้ ที่ตรงกันเพื่อทดสอบ หากใช้ JavaRegex ระบบจะเปรียบเทียบนิพจน์ทั่วไป กับสตริงหัวเรื่องทั้งหมด หากเรื่องคือ "abc" และนิพจน์ทั่วไปคือ "[a-z]" ไม่พบรายการที่ตรงกัน เนื่องจาก "[a-z]" ตรงกับอักขระอัลฟ่า1 ตัวพอดี นิพจน์ "[a-z]+" ใช้งานได้ เช่นเดียวกับ "[a-z]*" และ "[a-z]{3}

มาดูตัวอย่างที่เป็นรูปธรรมกัน สมมติว่าเซิร์ฟเวอร์การตรวจสอบสิทธิ์ส่งคืนรายการบทบาทเป็น สตริงที่คั่นด้วยเครื่องหมายจุลภาค เช่น "บรรณาธิการ ผู้เขียน แขก"

หากต้องการทดสอบการแสดงบทบาทผู้แก้ไข การสร้างนี้จะไม่ทำงาน เนื่องจาก "ผู้แก้ไข" เท่ากับ เพียงบางส่วนของสตริงทั้งหมด

<Condition>returned_roles ~~ "editor"</Condition>

อย่างไรก็ตาม การสร้างนี้จะทำงานดังนี้

<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>

ซึ่งได้ผลเพราะจะพิจารณาการแบ่งคำและส่วนอื่นๆ ของสตริงที่มี .* คำนำหน้าและคำต่อท้าย

ในตัวอย่างนี้ คุณยังสามารถทดสอบ "ตัวแก้ไข" ด้วยโอเปอเรเตอร์การจับคู่

<Condition>returned_roles ~~ "*editor*")</Condition>

อย่างไรก็ตาม ในกรณีที่คุณต้องการความแม่นยำมากขึ้น JavaRegex มักจะเป็นทางเลือกที่ดีกว่า

การใช้เครื่องหมายคำพูดคู่แบบ Escape ในนิพจน์ JavaRegex

ไวยากรณ์เงื่อนไขจำเป็นต้องมีนิพจน์ JavaRegex เพื่อรวมในเครื่องหมายคำพูดคู่ ดังนั้นหากคุณมี นิพจน์นิพจน์ทั่วไปที่มีเครื่องหมายคำพูดคู่ คุณต้องใช้วิธีอื่นในการจับคู่ คำตอบคือ Unicode ตัวอย่างเช่น สมมติว่าคุณส่งส่วนหัวที่มีเครื่องหมายคำพูดคู่ ดังนี้ 
 -H 'content-type:multipart/related; type="application/xop+xml"'
 หากคุณพยายามจับคู่ส่วนหัวนั้นในเงื่อนไขนิพจน์ทั่วไป คุณจะได้รับข้อผิดพลาด "เงื่อนไขไม่ถูกต้อง" เนื่องจากนิพจน์ มีเครื่องหมายคำพูดคู่ 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 โซลูชันคือการแทนที่เครื่องหมายคำพูดคู่แบบ ASCII ด้วย \u0022 ที่เทียบเท่า Unicode ตัวอย่างเช่น นิพจน์ต่อไปนี้ถูกต้องและสร้างผลลัพธ์ที่คาดหวัง 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"