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

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

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

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

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

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

<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} ดังนั้น หากต้องการประเมินส่วนหัว Content-type คุณสามารถใช้ตัวแปร 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 คำสั่งจะประเมินเป็นเท็จ

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

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

ตัวอย่างเช่น หากต้องการสร้างโฟลว์ที่ทำงานเฉพาะเมื่อคำกริยาของคำขอเป็น 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 มีผลเฉพาะในกรณีที่ข้อความคําขอเป็น 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 หากไม่เป็นเช่นนั้น ระบบจะไม่เรียกใช้ Flow และจะส่งคืนการตอบกลับ XML โดยไม่มีการแก้ไข (ในรูปแบบ XML) ไปยังแอปที่ส่งคำขอ

ตัวอย่างที่ 2

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

<XMLToJSON name="ConvertToJSON">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

การกำหนดค่านโยบายข้างต้นจะบอกให้พร็อกซี API รับข้อความตอบกลับ ทำการแปลงจาก XML เป็น JSON ด้วยการตั้งค่าเริ่มต้น แล้วเขียนผลลัพธ์ลงในข้อความตอบกลับใหม่ (หากคุณแปลงข้อความคำขอจาก XML เป็น JSON คุณเพียงแค่ตั้งค่าทั้ง 2 ค่านี้เป็น request)

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

<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

นโยบายทำงานไหม ใช่ ตรงกัน

คำถาม: ฉันจะหลีกเลี่ยงอักขระด้วยตัวดำเนินการ Matches ได้อย่างไร

ใช้อักขระเปอร์เซ็นต์ "%" เพื่อกำหนดอักขระที่สงวนไว้เป็นอักขระหลีก เช่น

<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

นโยบายทำงานไหม ได้ ตัวระบุปริมาณ "?" จะจับคู่กับอักขระ ก่อนหน้าซึ่งเป็น "a" 0 หรือ 1 ครั้ง

การเรียก API:

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

นโยบายทำงานไหม ได้ ตัวระบุปริมาณ "?" จะจับคู่กับอักขระที่นำหน้า หรือ ไม่จับคู่เลย ในกรณีนี้ไม่มีอักขระ "a" ดังนั้นเงื่อนไข จึงประเมินค่าเป็นจริง

การเรียก API:

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

นโยบายทำงานไหม ไม่ได้ ตัวระบุปริมาณ "?" จะจับคู่กับอักขระก่อนหน้าหนึ่งตัว ซึ่งก็คือ "a"

จากนั้นเราจะใช้รูปแบบนิพจน์ Regex "[abc]" หรือ "การจัดกลุ่ม" ซึ่งตรงกับอักขระ "a" หรือ "b" หรือ "c"

<Condition>(proxy.pathsuffix JavaRegex "/[cbr]at")</Condition>

การเรียก API:

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

นโยบายทำงานไหม ได้ เราใช้นิพจน์ทั่วไปที่นี่ และนิพจน์ "[cbr]" จะตรงกับ "c", "b" หรือ "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

นโยบายทำงานไหม ใช่ นิพจน์ทั่วไปจะจับคู่กับอักขระที่นำหน้า 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 รายการ

มาดูตัวอย่างกัน ในตัวอย่างนี้ เราจะทดสอบตัวแปร 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"

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

    <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 ฐานของนามแฝงที่แมปกับบริการแบ็กเอนด์เป็นอย่างน้อย เช่น

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

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

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

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

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

สมมติว่าคุณต้องการให้ Edge "ทำบางอย่าง" เมื่อมีการเรียกใช้ทรัพยากร /reports หรือ /forecasts ในขั้นตอนนี้ คุณไม่ได้บอก Edge ว่าต้องทำอะไร เพียงแต่บอกว่าควรฟังการเรียกทรัพยากรเหล่านั้น ซึ่งทำได้โดยใช้ เงื่อนไข ในพร็อกซี API ของ Edge คุณสามารถสร้างโฟลว์แบบมีเงื่อนไขสำหรับ /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

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

โดยคุณต้องเพิ่มโฟลว์แบบมีเงื่อนไข 2 รายการในพร็อกซี API ได้แก่ /developers และ /apps

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

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

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

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

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

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

ระบบจะทริกเกอร์เงื่อนไข (และดำเนินการตามนโยบาย) หากมีการส่งการเรียกไปยังพร็อกซี โดยมี /apps อยู่ท้าย URI และมีคำกริยา POST

ในแผง Navigator คุณจะเห็นโฟลว์ใหม่สำหรับแอปและ นักพัฒนาแอป

เลือกโฟลว์ใดโฟลว์หนึ่งเพื่อดูการกำหนดค่าโฟลว์แบบมีเงื่อนไขในมุมมองโค้ดของเครื่องมือแก้ไขพร็อกซี 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 แบบลำดับชั้น เช่น 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 อย่างเหมาะสม

/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 ต้องการจัดการทั้งคำต่อท้ายเส้นทาง "/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 คุณสามารถใช้การจับคู่รูปแบบกับสตริงหรือตัวแปรโฟลว์ใดก็ได้ ไม่ว่าจะเป็นตัวแปรโฟลว์ในตัว เช่น proxy.pathsuffix หรือไม่ก็ตาม

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

มาดูตัวอย่างที่เป็นรูปธรรมกัน สมมติว่าเซิร์ฟเวอร์การตรวจสอบสิทธิ์แสดงรายการบทบาทเป็น สตริงที่คั่นด้วยคอมมา "editor, author, guest"

หากต้องการทดสอบว่ามีบทบาทผู้แก้ไขหรือไม่ โครงสร้างนี้จะใช้ไม่ได้เนื่องจาก "editor" เป็น เพียงส่วนหนึ่งของสตริงทั้งหมด

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

อย่างไรก็ตาม โครงสร้างนี้จะใช้ได้

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

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

ในตัวอย่างนี้ คุณยังทดสอบ "เอดิเตอร์" ด้วยโอเปอเรเตอร์ตรงกันได้ด้วย

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

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

การหลีกเลี่ยงเครื่องหมายคำพูดคู่ในนิพจน์ JavaRegex

 -H 'content-type:multipart/related; type="application/xop+xml"'

request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"

request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"