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

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

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

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

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

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

<Condition></Condition>

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

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

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

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

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

ตัวแปร

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

ตัวแปรจะใช้สัญลักษณ์ที่มีจุดเสมอ เช่น ส่วนหัว HTTP ในข้อความคำขอจะแสดงเป็นตัวแปรที่เรียกว่า request.header.{header_name} ดังนั้นในการประเมินส่วนหัวประเภทเนื้อหา คุณอาจใช้ตัวแปร request.header.Content-type ได้ เช่น request.header.Content-type = "application/json" บ่งบอกว่าประเภทเนื้อหาของคำขอควรเป็น JSON

สมมติว่าคุณต้องสร้างคำสั่งแบบมีเงื่อนไขที่จะทำให้มีการบังคับใช้นโยบายเฉพาะเมื่อข้อความคำขอเป็น GET หากต้องการสร้างเงื่อนไขที่ประเมินคำกริยา HTTP ของคำขอ คุณจะต้องสร้างคำสั่งแบบมีเงื่อนไขที่ด้านล่าง ตัวแปรในเงื่อนไขนี้คือ request.verb ค่าของตัวแปรคือ GET โอเปอเรเตอร์คือ =

<Condition>request.verb = "GET"</Condition>
หรือคุณยังสามารถใช้สิ่งต่อไปนี้
<Condition>request.verb equals "GET"</Condition>

Edge ใช้ข้อความดังกล่าวเพื่อประเมินเงื่อนไขต่างๆ ตัวอย่างด้านบนจะประเมินค่าเป็นจริง หากกริยา HTTP ที่เชื่อมโยงกับคำขอคือ GET หากกริยา HTTP ที่เชื่อมโยงกับคำขอเป็น POST คำสั่งจะประเมินค่าเป็นเท็จ

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

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

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

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

วิธีสร้างโฟลว์สำหรับ GET และอีก 1 โฟลว์สำหรับ POST

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

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

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

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

สำหรับข้อมูลอ้างอิงที่ครอบคลุม โปรดดูแหล่งข้อมูลต่อไปนี้

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

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

<Flows>
  <Flow name="Convert-for-devices">
  <Condition>(request.header.User-Agent = "Mozilla")</Condition>
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

Edge จะจัดเก็บค่าของส่วนหัว HTTP ทั้งหมดที่แสดงเป็นตัวแปรสำหรับคำขอแต่ละรายการที่ได้รับจากแอป หากคำขอมีส่วนหัว HTTP ที่เรียกว่า User-Agent ระบบจะจัดเก็บส่วนหัวและค่านั้นเป็นตัวแปรที่ชื่อ request.header.User-Agent

จากการกำหนดค่า ProxyEndpoint ข้างต้น Edge จะตรวจสอบค่าของตัวแปร request.header.User-Agent เพื่อดูว่าเงื่อนไขประเมินค่าเป็นจริงหรือไม่

หากเงื่อนไขประเมินเป็น "จริง" นั่นก็คือค่าของตัวแปร request.header.User-Agent เท่ากับ Mozilla โฟลว์แบบมีเงื่อนไขจะทำงานและบังคับใช้นโยบาย XMLtoJSON ที่เรียกว่า ConvertToJSON มิเช่นนั้น ระบบจะไม่ดำเนินการโฟลว์และจะส่งคืนการตอบสนอง XML ไม่มีการแก้ไข (ในรูปแบบ XML) ไปยังแอปที่ส่งคำขอ

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

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

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

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

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

<Flows>
  <Flow name="Convert-for-devices">
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

เมื่อเรียกใช้ API โดยใช้คำขอมาตรฐาน การตอบกลับจะอยู่ในรูปแบบ JSON

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

ทดสอบโฟลว์แบบมีเงื่อนไข

ในคำขอตัวอย่างนี้ ส่วนหัว HTTP User-Agent มีการตั้งค่าเป็น Mozilla ซึ่งทำให้คำสั่งแบบมีเงื่อนไขประเมินเป็น "จริง" และโฟลว์แบบมีเงื่อนไข Convert-for-devices ทำงาน

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

หรือหากต้องการพิมพ์ให้สวยในพื้นที่ที่มี Python ให้บริการ:

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282 | python -mjson.tool

ตัวอย่างคำตอบ:

. . .

"yweather_forecast": [
         {
              "code": "11",
              "date": "12 Dec 2012",
              "day": "Wed",
              "high": "55",
              "low": "36",
              "text": "Showers"
          },
          {
              "code": "32",
              "date": "13 Dec 2012",
              "day": "Thu",
              "high": "56",
              "low": "38",
              "text": "Sunny"
          }
      ]
  }

. . .

คำขอที่ส่งโดยไม่มีส่วนหัว User-Agent หรือมีค่าอื่นที่ไม่ใช่ Mozilla จะทำให้ได้รับการตอบกลับในรูปแบบ XML

$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

การตอบกลับ XML ที่ไม่มีการแก้ไขจะปรากฏขึ้น

ตัวอย่างคำตอบ:

<yweather:forecast day="Wed" date="12 Dec 2012" low="36" high="55" text="Showers" code="11" /> <yweather:forecast day="Thu" date="13 Dec 2012" low="38" high="56" text="Sunny" code="32" />

การจับคู่รูปแบบ

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

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

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

ตรงกับ

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

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

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

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

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

การเรียก API

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

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

ลองนึกถึงข้อความแบบมีเงื่อนไขนี้ที่เราใช้อักขระไวลด์การ์ด "*"

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

การเรียก API

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

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

การเรียก API:

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

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

การเรียก API:

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

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

ต่อไปให้ย้ายสัญลักษณ์แทนไปที่ส่วนท้ายของส่วนต่อท้าย

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

การเรียก API

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

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

การเรียก API:

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

นโยบายทํางานหรือไม่ ไม่ "/bat" ไม่ตรงกัน

การเรียก API

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

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

การเรียก API

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

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

คำถาม: ตัวดำเนินการจับคู่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หรือไม่

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

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

การเรียก API

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

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

การเรียก API

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

นโยบายทํางานหรือไม่ ใช่ กรณีนี้ตรง

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

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

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

การเรียก API

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

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

การเรียก API

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

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

ใช่ เส้นทางนี้จับคู่กันแม้จะแปลกๆ เล็กน้อย

JavaRegex

จะเห็นได้ว่าโอเปอเรเตอร์ "การจับคู่ที่ตรงกัน" เหมาะสำหรับสถานการณ์ทั่วไป แต่คุณใช้โอเปอเรเตอร์อื่น ซึ่งก็คือโอเปอเรเตอร์ "JavaRegex" หรือ "~~" ได้ 2 รายการนี้เป็นโอเปอเรเตอร์เดียวกัน ยกเว้น JavaRegex จะถือว่าอ่านได้มากกว่า โดยมีชื่อว่า JavaRegex เพราะใช้การจับคู่รูปแบบนิพจน์ทั่วไปได้และ Edge จะใช้กฎเดียวกันกับคลาสในแพ็กเกจ java.util.regex ในภาษา Java วิธีการทํางานของโอเปอเรเตอร์ JavaRegex แตกต่างจากโอเปอเรเตอร์ "การจับคู่" เป็นอย่างมาก ดังนั้นจึงไม่ควรสับสนระหว่างทั้ง 2 รายการนี้

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

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

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

คำถาม: คำต่อท้ายเส้นทางพร็อกซีใดจะทำให้ SomePolicy ทำงาน ในกรณีนี้มีเพียงโอเปอเรเตอร์เดียวที่เป็นไปได้เช่นเดียวกับโอเปอเรเตอร์การจับคู่

การเรียก API

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

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

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

<Condition>(proxy.pathsuffix JavaRegex "/c*t")</Condition>

การเรียก API

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

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

การเรียก API:

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

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

ถัดไป เราใช้ตัวระบุ "?" ซึ่งตรงกับอักขระนำหน้า 1 ครั้ง หรือไม่จับคู่เลย

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

การเรียก API

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

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

การเรียก API:

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

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

การเรียก API:

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

นโยบายทํางานหรือไม่ ไม่ ตัวขยาย "?" ตรงกับอักขระ 1 ตัวที่นำหน้าซึ่งเป็น "a"

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

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

การเรียก API

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

นโยบายทํางานหรือไม่ ได้ เราใช้นิพจน์ทั่วไปที่นี่ และนิพจน์ "[cbr]" ตรงกับ "c", "b", OR "r" การโทรเหล่านี้ยังตรงกับ

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

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

แต่ข้อมูลนี้ไม่ตรงกัน

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

คำถาม: โอเปอเรเตอร์ JavaRegex พิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หรือไม่

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

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

การเรียก API

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

นโยบายทํางานหรือไม่ ใช่ regex จะจับคู่ 0 หรืออักขระข้างหน้า 1 ตัว ซึ่งก็คือ "a"

การเรียก API

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

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

ไม่ เนื่องจากอักษรตัวพิมพ์ใหญ่ "A" ไม่ตรงกับตัวอักษรพิมพ์เล็ก "a"

MatchesPath

คุณยังระบุโอเปอเรเตอร์ MatchesPath แบบนี้ "~/" ได้ด้วย ซึ่งมีลักษณะคล้ายกับโอเปอเรเตอร์ Matches (~) และ JavaRegex (~~) แต่ MatchesPath นั้นต่างออกไปโดยสิ้นเชิง

โปรดทราบว่าโอเปอเรเตอร์นี้จะดูเส้นทางเป็นชุดชิ้นส่วน ดังนั้น หากเส้นทางคือ /animals/cats/wild ก็ให้คิดว่าเส้นทางนั้นประกอบด้วยส่วน "/animals" "/cats" และ "/wild"

โอเปอเรเตอร์ MatchesPath ให้คุณใช้สัญลักษณ์ไวลด์การ์ดได้ 2 แบบ ได้แก่ เครื่องหมายดอกจัน (*) 1 อันและเครื่องหมายดอกจัน 2 ตัว (**) เครื่องหมายดอกจันเดี่ยวจะตรงกับองค์ประกอบเส้นทาง 1 องค์ประกอบ โดยเครื่องหมายดอกจันคู่จะตรงกับองค์ประกอบเส้นทางอย่างน้อย 1 รายการ

ยกตัวอย่างเช่น ในตัวอย่างนี้ เราทดสอบตัวแปร proxy.pathsuffix ซึ่งเป็นตัวแปรบิวท์อินใน Edge ที่เก็บคำต่อท้ายเส้นทางของคำขอ อย่างไรก็ตาม โปรดทราบว่าคุณทดสอบค่าของตัวแปรโฟลว์ทั้งหมดที่มีสตริงได้

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

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

การเรียก API

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

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

ไม่ได้ เนื่องจากเงื่อนไขต้องมีองค์ประกอบเส้นทางอื่นหลัง "/animals" ตามที่ระบุโดย "/*"

การเรียก API

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

นโยบายทํางานหรือไม่ ใช่ เส้นทางมีองค์ประกอบอื่นของเส้นทาง (ส่วนที่อยู่หลัง "/animals/") แต่องค์ประกอบว่างเปล่า

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

นโยบายทํางานหรือไม่ ใช่ เนื่องจากเส้นทางมีองค์ประกอบ ("/cats") ที่อยู่หลัง "/animals" อย่างชัดเจน

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

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

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

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

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

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

การเรียก API

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

นโยบายทํางานหรือไม่ ไม่ เนื่องจากเงื่อนไขต้องมีองค์ประกอบเส้นทางต่อไปนี้อย่างน้อย 1 รายการที่ระบุโดย "/**"

การเรียก API

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

นโยบายทํางานหรือไม่

ใช่ เส้นทางมีองค์ประกอบอื่นของเส้นทาง (ส่วนที่อยู่หลัง "/animals/") แต่องค์ประกอบว่างเปล่า

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

นโยบายทํางานหรือไม่

ใช่ เนื่องจากเส้นทางมีองค์ประกอบอย่างน้อย 1 รายการที่ตามหลัง "/animals"

การเรียก API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

นโยบายทํางานหรือไม่

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

เครื่องหมายดอกจันผสม

คุณสามารถใช้การผสมระหว่างเครื่องหมายดอกจัน (*) เดี่ยว (*) และคู่ (**) เพื่อปรับแต่งการจับคู่เส้นทางเพิ่มเติมได้

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*/wild/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

การเรียก API

การเรียก API เหล่านี้ทั้งหมดจะทำให้เกิดการจับคู่:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild/

และ

GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian

และ

GET http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches

ทรัพยากร API

บริการ RESTful คือคอลเล็กชันของทรัพยากร API ทรัพยากร API คือส่วนย่อยของเส้นทาง URI ที่ระบุเอนทิตีบางอย่างที่นักพัฒนาซอฟต์แวร์เข้าถึงได้ด้วยการเรียก API ของคุณ ตัวอย่างเช่น หากบริการของคุณมีรายงานสภาพอากาศและพยากรณ์อากาศ บริการแบ็กเอนด์อาจกำหนดทรัพยากร API 2 รายการดังนี้

  • http://mygreatweatherforecast.com/reports
  • http://mygreatweatherforecast.com/forecasts

เมื่อสร้างพร็อกซี API (ดังที่แสดงในสร้างพร็อกซี API แรกของคุณ) อย่างน้อยจะเป็นการสร้าง URL ฐานของชื่อแทนที่แมปกับบริการแบ็กเอนด์ เช่น

URL ฐานของแบ็กเอนด์ URL พร็อกซี API ใหม่/ที่เทียบเท่า
http://mygreatweatherforecast.com http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

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

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

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

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

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

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

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
    </Flow>
    <Flow name="forecasts">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/forecasts") and (request.verb = "GET")</Condition>
    </Flow>
</Flows>

เงื่อนไขดังกล่าวระบุว่า "เมื่อมีคำขอ GET มาพร้อมกับ /reports และ /forecasts ใน URL แล้ว Edge จะทำทุกวิถีทางที่คุณ (นักพัฒนาซอฟต์แวร์ API) บอก ผ่านนโยบายที่คุณแนบไว้กับขั้นตอนเหล่านั้น

ตัวอย่างการบอกให้ Edge รู้ว่าต้องทำอะไรบ้างเมื่อตรงตามเงื่อนไข ใน XML ของพร็อกซี API ต่อไปนี้ เมื่อส่งคำขอ GET ไปยัง https://yourorg-test.apigee.net/mygreatweatherforecast/reports Edge จะดำเนินการตามนโยบาย "XML-to-JSON-1" ในการตอบกลับ

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response>
            <Step>
                <Name>XML-to-JSON-1</Name>
            </Step>
        </Response>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
</Flow>

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

สร้างโฟลว์แบบมีเงื่อนไขไปยังทรัพยากรแบ็กเอนด์

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

โดยคุณจะดำเนินการต่อไปนี้ได้

  • ใช้การจัดการในลักษณะที่สะท้อนอรรถศาสตร์ของโมเดล API ของคุณ
  • ใช้นโยบายและลักษณะการทำงานที่ใช้สคริปต์กับเส้นทางทรัพยากร (URI) แต่ละเส้นทาง
  • รวบรวมเมตริกแบบละเอียดสำหรับบริการ Analytics

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

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

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

ในหน้าต่าง "โฟลว์ตามเงื่อนไขใหม่" ให้ป้อนการกําหนดค่าคีย์ต่อไปนี้

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

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

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

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

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

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

เลือกขั้นตอนใดขั้นตอนหนึ่งเพื่อดูการกำหนดค่าโฟลว์แบบมีเงื่อนไขในมุมมองโค้ดของตัวแก้ไขพร็อกซี API

<Flow name="Apps">
    <Description>Developer apps registered in Developer Services</Description>
    <Request/>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition>
</Flow>

จะเห็นได้ว่าทรัพยากร API เป็นเพียงโฟลว์แบบมีเงื่อนไขที่ประเมินเส้นทาง URI ของคำขอขาเข้า (ตัวแปรproxy.pathsuffix ระบุ URI ของคำขอที่ตามหลัง BasePath ที่กําหนดค่าไว้ในการกําหนดค่า ProxyEndpoint)

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

เมื่อคุณทำให้พร็อกซี API ใช้งานได้กับสภาพแวดล้อมการทดสอบ คำขอต่อไปนี้

http://{org_name}-test.apigee.net/{proxy_path}/apps

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

เงื่อนไขตัวอย่างต่อไปนี้ใช้นิพจน์ทั่วไปของ Java เพื่อจดจำการเรียกไปยังทรัพยากร /apps ที่มีหรือไม่มีเครื่องหมายทับปิดท้าย (/apps หรือ /apps/**)

<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับเงื่อนไขประเภทนี้ที่วิธีจับคู่โดยไม่สนใจ ... ในชุมชน Apigee

การสร้างโมเดล URI แบบลำดับชั้น

ในบางกรณี คุณจะมีทรัพยากร API แบบลำดับชั้น เช่น Developer Services API มีวิธีแสดงแอปทั้งหมดที่เป็นของนักพัฒนาซอฟต์แวร์ เส้นทาง URI คือ

/developers/{developer_email}/apps

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

/genus/:id/species

เส้นทางนี้ใช้กับ URI ทั้งสองต่อไปนี้เท่าๆ กัน:

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

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

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

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

ในบางกรณี โดยเฉพาะสำหรับ API ที่มีลำดับชั้นบางขั้น คุณอาจต้องการแก้ไขทุกอย่างที่อยู่ใต้ส่วนย่อย URI บางรายการ ในการดำเนินการ ให้ใช้ไวลด์การ์ดที่มีเครื่องหมายดอกจัน 2 ตัวในคำจำกัดความทรัพยากร เช่น หากคุณกำหนดทรัพยากร API ต่อไปนี้
/developers/**

ทรัพยากร API ดังกล่าวจะแก้ไขเส้นทาง URI ต่อไปนี้

/developers/{developer_email}/apps
/developers/{developer_email}/keys
/developers/{developer_email}/apps/{app_id}/keys

เงื่อนไขของโฟลว์แบบมีเงื่อนไขในคำจำกัดความของพร็อกซี API มีดังนี้

<Condition>(proxy.pathsuffix MatchesPath "/developers/**") and (request.verb = "POST")</Condition>

ตัวอย่างอื่นๆ

แนบเงื่อนไขกับ RouteRule แล้ว

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.content-type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

แนบเงื่อนไขกับนโยบายแล้ว

<Step>
<!--the policy MaintenancePolicy only executes if the response status code is exactly 503-->
  <Condition>response.status.code = 503</Condition>
  <Name>MaintenancePolicy</Name>
</Step>

โฟลว์แบบมีเงื่อนไข

<!-- this entire flow is executed only if the request verb is a GET-->
<Flow name="GetRequests">
  <Condition>request.verb="GET"</Condition>
  <Request>
    <Step>
<!-- this policy only executes if request path includes a term like statues-->
<Condition>request.path ~ "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
<!-- this condition has multiple expressions. The policy executes if the response code status is exactly 503 or 400-->
<Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

โอเปอเรเตอร์ตัวอย่างในเงื่อนไข

ตัวอย่างโอเปอเรเตอร์ที่ใช้สร้างเงื่อนไขมีดังนี้

  • request.header.content-type = "text/xml"
  • request.header.content-length < 4096 && request.verb = "PUT"
  • response.status.code = 404 || response.status.code = 500
  • request.uri MatchesPath "/*/statuses/**"
  • request.queryparam.q0 NotEquals 10

ตัวอย่างที่ใช้ได้จริง: ละเว้น "/" ที่ส่วนท้ายของเส้นทาง

นักพัฒนาซอฟต์แวร์ Edge มักต้องการจัดการคำต่อท้ายเส้นทางทั้ง 2 แบบ ได้แก่ "/cat" และ "/cat/" เนื่องจากผู้ใช้บางรายหรือไคลเอ็นต์บางรายอาจเรียกใช้ API ของคุณด้วยเครื่องหมายทับเพิ่มเติมในส่วนท้ายของเส้นทาง และคุณต้องจัดการเรื่องดังกล่าวได้ในคำสั่งแบบมีเงื่อนไข กรณีการใช้งานที่แน่นอนนี้ มีการพูดคุยกันในชุมชน Apigee

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

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

ซึ่งถือเป็นตัวเลือกที่ดี ชัดเจนและอ่านออก

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

<Condition>(proxy.pathsuffix JavaRegex "/cat(/?)"</Condition>

การเรียก API

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

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

นโยบายทํางานหรือไม่ ได้ โปรดทราบว่าในนิพจน์ทั่วไป อักขระ "?" หมายถึงตรงกับอักขระ 0 หรือตัวใดตัวหนึ่งที่อยู่ก่อนหน้า ดังนั้น ทั้ง "/cat" และ "/cat/" จะถือว่าตรงกัน

การเรียก API:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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