วิธีทดสอบ SOAP API ออนไลน์: เครื่องมือและตัวอย่างการใช้งานจริง

SOAP ยังคงมีอยู่ ระบบธนาคาร เกตเวย์การชำระเงิน บริการของรัฐบาล และแพลตฟอร์มองค์กรเก่าๆ ยังคงเปิดเผย SOAP endpoints และต้องมีคนทดสอบมัน หากคุณใช้ชีวิตการทำงานอยู่กับ REST และ JSON บริการ SOAP อาจรู้สึกแปลกแยก โปรโตคอลนี้เข้มงวดกว่า เพย์โหลดเป็น XML และสัญญา (contract) อยู่ในไฟล์ WSDL แยกต่างหาก

ข่าวดีคือการทดสอบ SOAP API ออนไลน์ไม่ใช่เรื่องยาก เมื่อคุณเข้าใจว่ามันต้องการอะไรจากคุณจริงๆ คู่มือนี้จะอธิบายความแตกต่างของการทดสอบ SOAP กับ REST แนะนำการร้องขอจริง และครอบคลุมเครื่องมือออนไลน์ที่จัดการ SOAP ได้โดยไม่ต้องยุ่งยาก

ทำไมการทดสอบ SOAP ถึงแตกต่าง

REST เป็นรูปแบบ (style) SOAP เป็นโปรโตคอลที่มีกฎเกณฑ์ ความแตกต่างนี้กำหนดทุกสิ่งทุกอย่างเกี่ยวกับวิธีการทดสอบ

ข้อความ SOAP เป็นเอกสาร XML ที่ถูกห่อหุ้มด้วยซองจดหมาย (envelope) เสมอ ซองจดหมายมีส่วนหัว (header) สำหรับข้อมูลเมตา เช่น การรับรองความถูกต้องหรือการกำหนดเส้นทาง และส่วนเนื้อหา (body) ที่บรรจุการดำเนินการจริงและพารามิเตอร์ของมัน คุณไม่สามารถส่งเพียงแค่ JSON object ลอยๆ ได้ โครงสร้างเป็นสิ่งจำเป็น และซองจดหมายที่จัดรูปแบบไม่ถูกต้องจะถูกปฏิเสธก่อนที่ตรรกะของคุณจะเริ่มทำงาน SOAP เกือบทั้งหมดเดินทางผ่าน HTTP POST แม้แต่สำหรับการดำเนินการที่อ่านข้อมูลเท่านั้น และคาดว่าจะใช้ Content-Type ที่เฉพาะเจาะจง โดยปกติคือ text/xml หรือ application/soap+xml

ความแตกต่างที่สำคัญที่สุดในทางปฏิบัติคือ WSDL WSDL หรือ Web Services Description Language file เป็นสัญญาที่เครื่องอ่านได้ ซึ่งระบุทุกการดำเนินการที่บริการเสนอ รูปแบบที่แน่นอนของการร้องขอและการตอบกลับแต่ละรายการ และที่อยู่ endpoint REST แทบจะไม่ส่งมอบสิ่งที่เข้มงวดขนาดนี้ เมื่อคุณทดสอบ SOAP WSDL คือแผนที่ของคุณ เครื่องมือทดสอบ SOAP ออนไลน์ที่ดีจะอ่าน WSDL และสร้างแม่แบบการร้องขอให้คุณ คุณจึงไม่ต้องพิมพ์ซองจดหมายด้วยตนเอง หากคุณต้องการภาพรวมสัญญาที่กว้างขึ้น บันทึกของเราเกี่ยวกับ การทดสอบ API contract อธิบายว่าทำไมสัญญาที่เข้มงวดจึงเป็นทรัพย์สิน

คำร้องขอ SOAP จริงๆ แล้วเป็นอย่างไร

นี่คือคำร้องขอ SOAP ที่สมจริงสำหรับบริการแปลงสกุลเงิน สังเกตซองจดหมาย (envelope) การประกาศ namespace และการดำเนินการที่ซ้อนอยู่ในส่วนเนื้อหา (body)

POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Header>
    <cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
  </soap:Header>
  <soap:Body>
    <cur:ConvertAmount>
      <cur:FromCurrency>USD</cur:FromCurrency>
      <cur:ToCurrency>EUR</cur:ToCurrency>
      <cur:Amount>250.00</cur:Amount>
    </cur:ConvertAmount>
  </soap:Body>
</soap:Envelope>

การตอบกลับจะถูกห่อหุ้มในลักษณะเดียวกัน:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Body>
    <cur:ConvertAmountResponse>
      <cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
    </cur:ConvertAmountResponse>
  </soap:Body>
</soap:Envelope>

มีสองรายละเอียดที่ทำให้คนสับสน Header HTTP SOAPAction เป็นสิ่งจำเป็นสำหรับหลายบริการ และต้องตรงกับการดำเนินการ มิฉะนั้นคุณจะได้รับข้อผิดพลาด (fault) และเมื่อมีบางอย่างผิดพลาด SOAP จะไม่ส่งคืน HTTP 400 พร้อมข้อความที่ชัดเจน มันจะส่งคืน HTTP 200 พร้อมองค์ประกอบ <soap:Fault> ภายในส่วนเนื้อหา การทดสอบของคุณต้องแยกวิเคราะห์ส่วนเนื้อหาเพื่อทราบว่าการเรียกประสบความสำเร็จจริงหรือไม่ การตรวจสอบเพียงรหัสสถานะไม่เพียงพอ ซึ่งเป็นเหตุผลหนึ่งที่ทำให้ การยืนยัน API ที่มีโครงสร้างมีความสำคัญมากกว่าที่นี่เมื่อเทียบกับ REST

เครื่องมือออนไลน์สำหรับทดสอบ SOAP APIs

Apidog

Apidog จัดการ SOAP พร้อมกับ REST, GraphQL และ WebSocket ในที่เดียว คุณนำเข้า WSDL และมันจะสร้างโครงสร้างคำขอให้คุณ คุณจึงไม่ต้องสร้างซองจดหมายด้วยตนเอง คุณสามารถเพิ่มการยืนยันบนองค์ประกอบ XML, เชื่อมโยงคำขอเข้าเป็นสถานการณ์ และเรียกใช้ทั้งหมดเป็นชุดทดสอบอัตโนมัติ เนื่องจากมันยังออกแบบและจำลอง API คุณจึงสามารถจำลองการตอบกลับ SOAP ก่อนที่บริการจริงจะพร้อมใช้งาน ดาวน์โหลด Apidog เพื่อทดสอบบริการ SOAP ในระดับฟรี

SoapUI

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

Postman

Postman สามารถส่งคำขอ SOAP ได้ คุณตั้งค่าส่วนเนื้อหาเป็น XML ดิบ เพิ่มเฮดเดอร์ Content-Type และ SOAPAction ด้วยตนเอง และวางซองจดหมายของคุณลงไป มันทำงานได้ แต่ Postman ไม่แยกวิเคราะห์ WSDL ดังนั้นคุณต้องสร้างซองจดหมายด้วยตัวเอง มันเหมาะสำหรับการตรวจสอบเพียงครั้งเดียว แต่ไม่สะดวกสำหรับการใช้งาน SOAP ในวงกว้าง

เครื่องมือทดสอบ SOAP ที่ทำงานบนเบราว์เซอร์

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

ขั้นตอนการทดสอบ SOAP อย่างรวดเร็ว

1. รับ WSDL บริการ SOAP ส่วนใหญ่จะเปิดเผยโดยการเพิ่ม ?wsdl ต่อท้าย URL ของ endpoint เปิดมันและยืนยันว่าโหลดได้
2. นำเข้า WSDL เข้าสู่เครื่องมือของคุณ Apidog และ SoapUI สร้างแม่แบบคำขอจาก WSDL นี่คือสิ่งที่จะช่วยประหยัดเวลาได้มากที่สุด
3. กรอกพารามิเตอร์การดำเนินการ ใช้ค่าจริง ทดสอบการแปลงสกุลเงินด้วยจำนวนเงินจริงและรหัสสกุลเงินที่ถูกต้อง
4. ตั้งค่าเฮดเดอร์ ยืนยัน Content-Type และ SOAPAction เมื่อจำเป็น การขาด SOAPAction เป็นสาเหตุที่พบบ่อยที่สุดของข้อผิดพลาดที่ไม่สามารถอธิบายได้
5. ส่งและตรวจสอบส่วนเนื้อหา อย่าหยุดแค่สถานะ HTTP เปิดส่วนเนื้อหาของการตอบกลับและตรวจสอบหา <soap:Fault>
6. เพิ่มการยืนยัน ยืนยันว่ามีองค์ประกอบเฉพาะและมีค่าที่คาดไว้ จากนั้นเชื่อมโยงการเรียกติดตามผลหากเวิร์กโฟลว์ของคุณต้องการ

สำหรับการจัดระเบียบสิ่งเหล่านี้ให้เป็นชุดที่บำรุงรักษาได้ คู่มือของเราเกี่ยวกับ การสร้างชุดทดสอบสำหรับการทำงานอัตโนมัติของ API สามารถนำไปใช้กับงาน SOAP ได้โดยตรง

ข้อผิดพลาด SOAP และวิธีการยืนยัน

ข้อผิดพลาด SOAP คือโครงสร้างข้อผิดพลาดของโปรโตคอล มันมี faultcode, faultstring และบางครั้งมีองค์ประกอบ detail เนื่องจากมันมาพร้อมกับ HTTP 200 การทดสอบที่ตรวจสอบสถานะเพียงอย่างเดียวจะผ่านไปได้แม้จะมีการเรียกที่ล้มเหลว นี่เป็นผลบวกปลอมที่อันตรายอย่างเงียบๆ

เขียนการยืนยัน SOAP ของคุณให้มองเข้าไปในส่วนเนื้อหา ยืนยันว่าไม่มีองค์ประกอบ <soap:Fault> อยู่ในเส้นทางที่สำเร็จ ในเส้นทางข้อผิดพลาดที่จงใจ ให้ยืนยันในทางตรงกันข้ามว่าข้อผิดพลาดปรากฏขึ้นและ faultcode ตรงกับที่คุณคาดหวัง การทดสอบกรณีความล้มเหลวมีความสำคัญพอๆ กับเส้นทางที่ประสบความสำเร็จ เพราะบริการ SOAP มักจะเข้ารหัสกฎทางธุรกิจ เช่น ธุรกรรมที่ถูกปฏิเสธ เป็นข้อผิดพลาดแทนที่จะเป็นข้อมูล เอกสาร SOAP fault ของ W3C อธิบายโครงสร้างหากคุณต้องการรายละเอียดอย่างเป็นทางการ

WS-Security เพิ่มอีกชั้นหนึ่ง บริการ SOAP ระดับองค์กรจำนวนมากคาดหวังเฮดเดอร์ความปลอดภัยที่มีการลงนามหรือมีโทเค็น หากคำขอของคุณล้มเหลวด้วยข้อผิดพลาดการรับรองความถูกต้อง WSDL หรือเอกสารบริการจะระบุโปรไฟล์ความปลอดภัยที่ใช้งานอยู่ เครื่องมือเช่น SoapUI และ Apidog ช่วยให้คุณกำหนดค่าเฮดเดอร์เหล่านี้ได้แทนที่จะต้องเขียน XML ด้วยตนเอง

การอ่าน WSDL โดยไม่หลงทาง

ไฟล์ WSDL ดูน่ากลัวในครั้งแรกที่คุณเปิดมัน มันเป็น XML ที่ยาว มีการซ้อนกันลึก และส่วนใหญ่เป็นเรื่องของกลไกเครื่องจักร คุณไม่จำเป็นต้องอ่านทั้งหมด มีสี่ส่วนที่บรรจุข้อมูลที่คุณต้องการจริงๆ

ส่วน types กำหนดโครงสร้างข้อมูล โดยปกติเป็น XML Schema ดังนั้นนี่คือที่ที่คุณจะได้เรียนรู้รูปร่างและข้อจำกัดที่แน่นอนของแต่ละพารามิเตอร์ องค์ประกอบ message อธิบายอินพุตและเอาต์พุตสำหรับการดำเนินการแต่ละรายการ portType แสดงรายการการดำเนินการเอง ซึ่งเป็นการเรียกที่คุณสามารถทำได้ ส่วน service และ binding ให้ที่อยู่ endpoint ที่ชัดเจนและรายละเอียดการขนส่ง เมื่อคุณนำเข้า WSDL เข้าสู่เครื่องมือ มันจะอ่านทั้งสี่ส่วนและเปลี่ยนให้เป็นคำขอที่พร้อมแก้ไข นั่นคือเหตุผลที่การนำเข้าดีกว่าการพิมพ์ด้วยตนเองทุกครั้ง

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

การทดสอบ SOAP ที่ขับเคลื่อนด้วยข้อมูล

บริการ SOAP มักจะมีกฎทางธุรกิจที่เข้มงวด และคำขอแบบ happy-path เพียงครั้งเดียวแทบจะไม่สามารถพิสูจน์อะไรได้ บริการแลกเปลี่ยนสกุลเงินควรได้รับการทดสอบด้วยคู่สกุลเงินที่ถูกต้อง ด้วยสกุลเงินที่ไม่รองรับ ด้วยจำนวนเงินศูนย์ และด้วยจำนวนเงินติดลบ บริการชำระเงินควรได้รับการทดสอบด้วยบัตรที่อนุมัติ บัตรที่ถูกปฏิเสธ และบัตรที่หมดอายุ การพิมพ์แต่ละรายการด้วยตนเองนั้นช้าและผิดพลาดได้ง่าย

การทดสอบที่ขับเคลื่อนด้วยข้อมูลช่วยแก้ปัญหานี้ คุณเขียนคำขอเพียงครั้งเดียวโดยมีตัวยึดตำแหน่ง จากนั้นป้อนตารางแถวอินพุตและผลลัพธ์ที่คาดหวัง เครื่องมือจะเรียกใช้คำขอสำหรับแต่ละแถวและตรวจสอบแต่ละผลลัพธ์ SoapUI รองรับรูปแบบนี้มาหลายปีแล้ว และ Apidog ก็รองรับผ่านตัวเรียกใช้สถานการณ์ของมัน ผลตอบแทนคือการครอบคลุมกรณีขอบ (edge cases) ที่บริการ SOAP มักจะเข้ารหัสเป็นข้อผิดพลาด สำหรับรูปแบบที่กว้างขึ้น คู่มือของเราเกี่ยวกับ การทดสอบ API ที่ขับเคลื่อนด้วยข้อมูลด้วย CSV และ JSON อธิบายวิธีจัดโครงสร้างข้อมูลอินพุต และสามารถนำไปใช้กับ SOAP ได้เช่นเดียวกับ REST

คำถามที่พบบ่อย

ความแตกต่างระหว่างการทดสอบ SOAP และ REST คืออะไร?

การทดสอบ SOAP ทำงานกับโปรโตคอล XML ที่เข้มงวดพร้อมสัญญา WSDL, ซองจดหมายบังคับ และข้อผิดพลาดที่ส่งคืนภายในส่วนเนื้อหา HTTP 200 การทดสอบ REST มักจะเกี่ยวข้องกับ JSON, ข้อตกลงที่ไม่เข้มงวด และรหัสสถานะ HTTP ที่มีความหมาย การทดสอบ SOAP ต้องแยกวิเคราะห์ส่วนเนื้อหาของการตอบกลับเพื่อยืนยันความสำเร็จ; การทดสอบ REST มักจะเชื่อถือรหัสสถานะได้

ฉันจำเป็นต้องมี WSDL เพื่อทดสอบ SOAP API หรือไม่?

คุณสามารถส่งคำขอ SOAP ได้โดยไม่ต้องใช้ WSDL หากคุณทราบโครงสร้างซองจดหมายที่แน่นอนแล้ว แต่ WSDL ทำให้การทดสอบง่ายขึ้นมาก เพราะเครื่องมือจะสร้างแม่แบบคำขอที่ถูกต้องจากมัน บริการส่วนใหญ่เปิดเผย WSDL โดยการเพิ่ม ?wsdl ต่อท้าย URL ของ endpoint เริ่มต้นที่นั่นเสมอ

ทำไมคำขอ SOAP ของฉันถึงส่งคืนข้อผิดพลาด (fault) แม้ว่าสถานะจะเป็น 200?

SOAP รายงานข้อผิดพลาดเป็นองค์ประกอบ <soap:Fault> ภายในส่วนเนื้อหา ไม่ใช่รหัสข้อผิดพลาด HTTP ดังนั้นสถานะ 200 พร้อมข้อผิดพลาดจึงเป็นเรื่องปกติ สาเหตุทั่วไปคือเฮดเดอร์ SOAPAction หายไปหรือไม่ถูกต้อง, ซองจดหมายผิดรูปแบบ, namespace ไม่ตรงกัน หรือการตรวจสอบความปลอดภัยล้มเหลว อ่าน faultstring เพื่อดูสาเหตุเฉพาะ

ฉันสามารถทดสอบ SOAP APIs ออนไลน์ได้ฟรีหรือไม่?

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

ฉันจะทำการทดสอบ SOAP API แบบอัตโนมัติได้อย่างไร?

นำเข้า WSDL สร้างสถานการณ์ที่เชื่อมโยงการดำเนินการตามลำดับ เพิ่มการยืนยันบนองค์ประกอบการตอบกลับและเมื่อไม่มีข้อผิดพลาด จากนั้นเรียกใช้จากตัวรันของเครื่องมือหรือใน CI pipeline ของคุณ ทั้ง SoapUI และ Apidog รองรับชุดทดสอบ SOAP ที่กำหนดเวลาไว้และที่ถูกเรียกผ่าน pipeline ดังนั้นการเรียกใช้การทดสอบการถดถอยของ SOAP จึงเข้ากับขั้นตอนการทำงานอัตโนมัติแบบเดียวกับ REST