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

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

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

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

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

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

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

วิธีสร้าง Flow สำหรับ GET และอีก Flow สำหรับ 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 เพิ่ม Condition เป็นองค์ประกอบในเอนทิตีที่ใช้เงื่อนไขนั้น ในตัวอย่างนี้ เงื่อนไขเป็นองค์ประกอบของขั้นตอน ดังนั้น โฟลว์จะทำงานเมื่อใดก็ตามที่คำสั่งประเมินเป็น "จริง"

<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 ต่อไปนี้

<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 ตัวนี้เหมือนกัน โดยเวอร์ชันภาษาอังกฤษ "Matches" ถือเป็นตัวเลือกที่อ่านง่ายกว่า

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

XML ต่อไปนี้แสดงเงื่อนไข Step โดยจะเรียกใช้นโยบาย 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 แตกต่างจากโอเปอเรเตอร์ Matches อย่างมาก ดังนั้นคุณจึงไม่ควรสับสนระหว่าง 2 โอเปอเรเตอร์นี้

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

โค้ดต่อไปนี้แสดงเงื่อนไข Step โดยจะเรียกใช้นโยบาย 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

นโยบายทำงานไหม ได้ ตัวระบุปริมาณ "?" จะจับคู่กับอักขระก่อนหน้า 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" หรือ "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 รายการ เครื่องหมายดอกจัน 2 ตัวจะจับคู่กับองค์ประกอบเส้นทางอย่างน้อย 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"

ตอนนี้เรามาใช้เครื่องหมายดอกจัน 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, Edge ควรดำเนินการบางอย่าง"

รูปภาพต่อไปนี้แสดงความแตกต่างของลักษณะการทำงานระหว่าง URL 2 รายการที่เข้าถึงแบ็กเอนด์เดียวกันในท้ายที่สุด URL หนึ่งคือ URL ของทรัพยากรที่ไม่มีพร็อกซี ส่วนอีก 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

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

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

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

ในหน้าต่าง "New Conditional Flow" ให้ป้อนการกำหนดค่าหลักต่อไปนี้

  • ชื่อโฟลว์: นักพัฒนาแอป
  • ประเภทเงื่อนไข: เส้นทาง
  • เส้นทาง: /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 ของคำขอขาเข้า (ตัวแปร proxy.pathsuffix จะระบุ URI ของคำขอที่ตามหลัง BasePath ที่กำหนดค่าไว้ในการกำหนดค่า ProxyEndpoint)

ทรัพยากร API แต่ละรายการที่คุณกำหนดจะใช้งานโดย Flow แบบมีเงื่อนไขในพร็อกซี 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 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/

นโยบายทำงานไหม ได้ โปรดทราบว่าในนิพจน์ทั่วไป อักขระ "?" หมายถึงจับคู่กับอักขระก่อนหน้าศูนย์หรือหนึ่งรายการ ดังนั้นทั้ง "/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]" ตรงกับอักขระตัวอักษร 1 ตัวเท่านั้น นิพจน์ "[a-z]+" จะใช้ได้ เช่นเดียวกับ "[a-z]*" และ "[a-z]{3}

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

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

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

แต่โครงสร้างต่อไปนี้จะใช้ได้

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

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

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

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

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

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

ไวยากรณ์ของเงื่อนไขกำหนดให้นิพจน์ JavaRegex ต้องอยู่ในเครื่องหมายคำพูดคู่ ดังนั้นหากคุณมีนิพจน์ Regex ที่มีเครื่องหมายคำพูดคู่ คุณจะต้องใช้วิธีอื่นในการจับคู่ คำตอบคือ 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)"