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

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

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

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

วิดีโอ

ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรและเงื่อนไขของโฟลว์ได้ในวิดีโอต่อไปนี้

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

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

<Condition></Condition>

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

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

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

เมื่อใช้เส้นทาง URI คุณจะใช้ ~/ หรือ MatchesPath ได้ นอกจากนี้ คุณยังจับคู่นิพจน์ทั่วไป JavaRegex กับโอเปอเรเตอร์ ~~ ได้ด้วย

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

ตัวแปร

เงื่อนไขจะทำงานโดยการประเมินค่าของvariables ตัวแปรคือ ของธุรกรรม 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 คำสั่งจะประเมินเป็นเท็จ

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

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

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

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

วิธีสร้างโฟลว์ 1 รายการสําหรับ GET และอีก 1 รายการสําหรับ 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

อ่านเพิ่มเติม

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

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

• โอเปอเรเตอร์การจับคู่: การจับคู่รูปแบบอย่างง่าย
• โอเปอเรเตอร์ JavaRegex: ควบคุมการจับคู่ได้ดียิ่งขึ้น
• โอเปอเรเตอร์ MatchesPath: การจับคู่ชิ้นส่วนเส้นทาง

การจับคู่

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

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

XML ต่อไปนี้จะแสดงเงื่อนไขขั้นตอน โดยจะเรียกใช้นโยบาย SomePolicy เมื่อเงื่อนไขประเมินเป็น "จริง" ในตัวอย่างนี้ เราจะทดสอบตัวแปร proxy.pathsuffix ซึ่งเป็นตัวแปรในตัวของ Edge ที่เก็บส่วนต่อท้ายของเส้นทางของคําขอ อย่างไรก็ตาม โปรดทราบว่าคุณสามารถทดสอบค่าของตัวแปรการไหลที่มีสตริงได้ ดังนั้นในกรณีนี้ ถ้าเส้นทางฐานของ คำขอที่เข้ามาใหม่คือ /animals และคำขอคือ /animals/cat จากนั้น คำต่อท้ายเส้นทางคือสตริงตามตัวอักษร "/cat"

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix Matches "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดที่จะทำให้ somePolicy ทำงาน มี จะสามารถทำได้เพียงครั้งเดียว

การเรียก API:

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

นโยบายจะทำงานไหม ใช่ เนื่องจากคำต่อท้ายเส้นทางพร็อกซีตรงกับ "/cat" แน่นอน การดำเนินการจะไม่ทำงานหากส่วนต่อท้ายคือ /bat หรือ /dog หรือ "/" หรืออย่างอื่น

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

<Condition>(proxy.pathsuffix Matches "/*at")</Condition>

การเรียก API:

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

นโยบายมีผลบังคับใช้หรือไม่ ใช่ เนื่องจากไวลด์การ์ดตรงกับอักขระใดก็ได้ และ "/cat นิ้ว คือรายการที่ตรงกัน

การเรียก API:

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

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

การเรียก API:

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

นโยบายมีผลบังคับใช้หรือไม่ ไม่ได้ แม้ว่าไวลด์การ์ดจะตรงกับ "o" แต่ก็ไม่ได้ตรงกับตัวอักษร "wl"

ต่อไปเราจะย้ายไวลด์การ์ดไปยังส่วนท้ายของส่วนต่อท้าย

<Condition>(proxy.pathsuffix Matches "/cat*")</Condition>

การเรียก API:

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

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

การเรียก API:

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

นโยบายมีผลบังคับใช้หรือไม่ ไม่ "/bat" ไม่ใช่รายการที่ตรงกัน

การเรียก API:

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

นโยบายจะทำงานไหม ใช่ ไวลด์การ์ดจะจับคู่กับอักขระใดก็ได้ตั้งแต่ 0 ตัวขึ้นไป ดังนั้น "123" จึงจับคู่ได้

การเรียก API:

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

นโยบายจะทำงานไหม ใช่ เนื่องจากไวลด์การ์ดจะจับคู่กับอักขระใดก็ได้ตั้งแต่ 0 ตัวขึ้นไป ดังนั้น "/bird/mouse" จึงจับคู่ได้ โปรดทราบว่านิพจน์เช่นนี้อาจทําให้คุณมีปัญหาได้ เนื่องจากจะจับคู่กับทุกอย่างที่อยู่หลังอักขระตัวอักษร

คําถาม: โอเปอเรเตอร์ "ตรงกับ" จะคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ไหม

ได้ สมมติว่าคุณมีเงื่อนไขดังนี้

<Condition>(proxy.pathsuffix Matches "/*At")</Condition>

การเรียก API:

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

นโยบายมีผลบังคับใช้หรือไม่ ไม่ ไวลด์การ์ดจะจับคู่ตัวอักษรใดก็ได้ (โดยไม่คำนึงถึงตัวพิมพ์เล็กหรือใหญ่) แต่ ตัวพิมพ์เล็ก "a" ไม่ตรงกับ "A"

การเรียก API:

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

นโยบายมีผลบังคับใช้หรือไม่ ใช่ ตรงกัน

คำถาม: ฉันจะกำหนดอักขระหลีกด้วยโอเปอเรเตอร์การจับคู่ได้อย่างไร

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

<Condition>(proxy.pathsuffix Matches "/c%*at")</Condition>

การเรียก API:

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

นโยบายจะทำงานไหม ไม่ โอเปอเรเตอร์การจับคู่กำลังค้นหาสตริงตามตัวอักษร "c*at"

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/c*at

คำถาม:นโยบายดำเนินไปหรือไม่

ใช่ เส้นทางนี้อาจจะดูผิดปกติเล็กน้อย

JavaRegex

จะเห็นว่า "รายการที่ตรงกัน" เหมาะสำหรับสถานการณ์ง่ายๆ แต่คุณใช้โอเปอเรเตอร์อื่นได้ เช่น โอเปอเรเตอร์ "JavaRegex" หรือ "~~" 2 รายการนี้เป็นโอเปอเรเตอร์เดียวกัน ยกเว้น JavaRegex ที่ถือว่าอ่านง่ายกว่า เรียกเช่นนี้เนื่องจากอนุญาตให้จับคู่รูปแบบนิพจน์ทั่วไป และ 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 ทำงาน เช่นเดียวกับโอเปอเรเตอร์ "ตรงกับ" ในกรณีนี้จะมีเพียง 1 รูปแบบเท่านั้น

การเรียก 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 หนึ่งคือ 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

ในมุมมองการพัฒนาของแผง 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 ของคำขอขาเข้า (ตัวแปร 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 อย่างเหมาะสม

ในบางกรณี โดยเฉพาะสำหรับ 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

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

การจับคู่สตริงที่กำหนดเองกับ 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)"