คุณได้รับ SOAP endpoint มาใช้งาน อาจเป็นบริการแปลงสกุลเงินแบบเก่าที่ทีมบัญชียังต้องพึ่งพา หรือ Web Service สำหรับจัดการคำสั่งซื้อของพาร์ทเนอร์บน .NET งานของคุณคือเรียกใช้บริการ ยืนยันว่าคืนค่าตามสัญญา และทำให้การตรวจสอบนี้ทำซ้ำได้เมื่อโค้ดรอบข้างเปลี่ยนแปลงไป เครื่องมือ REST เพียงอย่างเดียวอาจไม่พอ เพราะ SOAP ต้องใช้ XML envelope, Content-Type ที่ถูกต้อง และ WSDL ที่อธิบาย operation ทั้งหมด
Apidog รองรับ SOAP และ WebService ควบคู่กับ REST, GraphQL และ gRPC จึงจัดการบริการเก่าและ API สมัยใหม่ใน Workspace เดียวได้ บทความนี้ครอบคลุม 2 วิธี:
- ส่ง SOAP request ด้วยตนเอง
- นำเข้า WSDL เพื่อสร้าง endpoint และ environment อัตโนมัติ
หากต้องการเปรียบเทียบโปรโตคอลก่อนเริ่ม อ่าน REST, GraphQL, gRPC และ SOAP และดูโครงสร้างมาตรฐานได้จาก ข้อกำหนด SOAP ของ W3C
SOAP คืออะไร และทำไมจึงต้องจัดการต่างจาก REST
SOAP ย่อมาจาก Simple Object Access Protocol เป็นโปรโตคอลสื่อสารแบบ XML ที่ช่วยให้ระบบต่างแพลตฟอร์มและภาษาต่างกันสื่อสารผ่านสัญญาเดียวกันได้ เช่น Java client เรียกใช้บริการ .NET โดยไม่ต้องรู้รายละเอียดภายในของอีกฝ่าย
เมื่อทดสอบ SOAP ให้โฟกัส 3 จุด:
- รูปแบบข้อความเป็น XML — ทั้ง request และ response เป็นเอกสาร XML ที่มีโครงสร้าง
- มักส่งผ่าน HTTP/HTTPS — แต่ SOAP รองรับ transport อื่นได้เช่นกัน
- โครงสร้างเข้มงวด — namespace, envelope, header และ body ต้องตรงตามสัญญาของบริการ
หากต้องการทบทวน XML ดู เอกสาร XML ของ MDN ได้
ความเข้มงวดนี้ทำให้ SOAP ยังเหมาะกับงานอย่างการเชื่อมต่อระบบเก่ากับระบบใหม่ การรวมระบบข้ามแพลตฟอร์ม และธุรกรรมที่ใช้ WS-Security สำหรับการยืนยันตัวตนหรือเข้ารหัสข้อความ คุณจึงไม่สามารถส่ง JSON แบบ REST ไปยัง SOAP endpoint ได้โดยตรง ต้องส่ง header และ XML envelope ที่ถูกต้องเสมอ
อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ envelope และ XML ได้ที่ SOAP API และ XML
ก่อนเริ่มต้น
ก่อนส่ง SOAP หรือ WebService request ให้ตรวจสอบว่า Apidog เป็นเวอร์ชัน 2.1.31 หรือใหม่กว่า เพราะเวอร์ชันก่อนหน้านี้ไม่รองรับ
เตรียมข้อมูลต่อไปนี้ให้พร้อม:
- URL ของ endpoint
- ชื่อ operation ที่ต้องการเรียก
- พารามิเตอร์ของ operation
- ไฟล์ WSDL หากบริการมีให้
WSDL อธิบาย operation, input, binding และ service address ของบริการ SOAP ดูโครงสร้างมาตรฐานได้ที่ WSDL 2.0
วิธี A: ส่ง SOAP request ด้วยตนเอง
ใช้วิธีนี้เมื่อคุณมี endpoint อยู่แล้ว และทราบ operation กับพารามิเตอร์ที่ต้องเรียก
ขั้นตอนที่ 1: ตั้งค่า Content-Type
SOAP ไม่อนุมาน header ให้เอง จึงต้องกำหนด Content-Type ในแท็บ Headers ของ request ด้วยตนเอง
ค่าที่พบบ่อยมี 2 แบบ:
text/xml; charset=utf-8
application/soap+xml
โดยทั่วไป:
| เวอร์ชัน SOAP | Content-Type ที่มักใช้ |
|---|---|
| SOAP 1.1 | text/xml; charset=utf-8 |
| SOAP 1.2 | application/soap+xml |
ตรวจสอบ WSDL หรือเอกสารของบริการก่อน หากส่งแล้วได้ข้อผิดพลาดเกี่ยวกับ Content-Type ให้ตรวจสอบว่า endpoint ต้องการ SOAP เวอร์ชันใด
ขั้นตอนที่ 2: ตั้งค่า Body เป็น XML และวาง SOAP envelope
เลือก Body type เป็น xml แล้ววาง SOAP envelope ที่ประกอบด้วย:
-
Envelopeสำหรับกำหนด namespace -
Bodyสำหรับห่อ operation - element ของ operation และพารามิเตอร์
ตัวอย่างต่อไปนี้เรียก operation NumberToWords พร้อมพารามิเตอร์ ubiNum:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://www.dataaccess.com/webservicesserver/">
<soap:Body>
<web:NumberToWords>
<web:ubiNum>1234</web:ubiNum>
</web:NumberToWords>
</soap:Body>
</soap:Envelope>
จุดที่ต้องตรวจสอบ:
- namespace
xmlns:webต้องตรงกับที่บริการกำหนด - ชื่อ operation ต้องตรงกับ WSDL
- ชื่อและลำดับของพารามิเตอร์ต้องตรงกับสัญญา
-
soap:Bodyต้องห่อ operation ทั้งหมด
อย่าเดา namespace เอง หากมี WSDL ให้ใช้ค่า namespace จาก WSDL เสมอ
ขั้นตอนที่ 3: ส่ง request และตรวจสอบ XML response
เมื่อส่ง request สำเร็จ response จะกลับมาเป็น SOAP envelope เช่น:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
<m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
</m:NumberToWordsResponse>
</soap:Body>
</soap:Envelope>
ตรวจสอบอย่างน้อย 3 อย่าง:
- response มี
soap:Envelopeและsoap:Body - มี node response ของ operation เช่น
NumberToWordsResponse - ค่าใน result ตรงตามที่คาดหวัง เช่น
NumberToWordsResult
รูปแบบเดียวกันนี้ใช้กับบริการอื่นได้ ตัวอย่างเช่น:
-
ConvertCurrencyส่งfromCurrency,toCurrency,amount -
GetOrderStatusส่งorderId - ตรวจสอบค่าที่คืนมาใน response node ของ operation นั้น
กลไกหลักไม่เปลี่ยน:
กำหนด Header → วาง XML envelope → ส่ง request → ตรวจสอบ response envelope
ดูตัวอย่าง envelope และการตั้งค่าเพิ่มเติมได้ที่ webservice.apidog.io
วิธี B: นำเข้า WSDL เพื่อสร้าง endpoint
หากบริการมี operation จำนวนมาก การพิมพ์ envelope ทีละรายการไม่ใช่วิธีที่เหมาะสม ให้ import WSDL เพื่อให้ Apidog อ่าน operation, input และ service address จากไฟล์
ทำตามขั้นตอนนี้:
- ไปที่ Settings
- เลือก Import Data
- เลือก
WSDL - อัปโหลดไฟล์
.wsdlหรือ.xml - ตรวจสอบ preview ของ endpoint ที่ Apidog แยกวิเคราะห์
- เปิดแท็บ
Environmentsและตรวจสอบ service address - คลิก
Confirm - เลือก environment ที่นำเข้าจากมุมขวาบน
- ส่ง request
ตรวจสอบ service address ก่อนกด Confirm
ขั้นตอนนี้สำคัญ เพราะ service address ใน WSDL จะกลายเป็น Base URL ของ request ที่นำเข้า
หาก WSDL ชี้ไปยัง:
- test server
- staging server
- host เก่าที่ไม่ได้ใช้งานแล้ว
- URL ชั่วคราว
request ทั้งหมดอาจถูกส่งไปผิดปลายทาง ตรวจสอบค่าในแท็บ Environments ก่อนคลิก Confirm
เลือก environment ที่นำเข้าแล้วก่อนส่ง request
หลัง import แล้ว Apidog จะสร้าง environment ให้อัตโนมัติ และ Base URL จะถูกผูกไว้กับ environment นี้
หากไม่เลือก environment จากมุมขวาบน request อาจไม่มี Base URL และล้มเหลวได้
หลังจากนำเข้า operation แต่ละรายการจะปรากฏเป็น endpoint ที่เรียกใช้ได้ โดยไม่ต้องเขียน SOAP envelope เอง และคุณยังตรวจสอบ XML response ได้เหมือนวิธี A
หากกำลังย้ายโปรเจกต์ SOAP ทั้งหมด อ่าน คู่มือนำเข้าโปรเจกต์ SOAP
การนำเข้า WSDL ที่ระบุไว้รองรับไฟล์
.wsdlและ.xmlเอกสารไม่ได้ระบุการนำเข้าจาก URL หรือการวาง WSDL โดยตรง ดังนั้นควรอัปโหลดไฟล์
ย้ายจาก SoapUI
หากมี SOAP test อยู่ใน SoapUI แล้ว ไม่จำเป็นต้องสร้างใหม่ทั้งหมด ให้เก็บหรือ export WSDL แล้ว import เข้า Apidog ด้วยวิธี B
ผลลัพธ์คือ operation เดิมจะกลายเป็น endpoint ที่เรียกใช้ได้ใน Workspace เดียวกับ:
- REST endpoint
- GraphQL request
- mock
- เอกสาร API
- test scenario
อ่านรายละเอียดการย้ายและความแตกต่างของ workflow ได้ที่ Apidog กับ SoapUI
เพิ่มการยืนยันผลลัพธ์และสร้าง test scenario
การเรียกสำเร็จหนึ่งครั้งเพียงพิสูจน์ว่า endpoint ตอบกลับได้ แต่ยังไม่ยืนยันว่าผลลัพธ์ถูกต้องตามสัญญา
สำหรับ SOAP response ให้เพิ่มการตรวจสอบที่ระดับ response envelope:
- ตรวจสอบว่ามี response node ที่คาดหวัง
- ดึงค่า result node
- เปรียบเทียบค่ากับ expected value หรือเงื่อนไขที่ยอมรับได้
ตัวอย่างเงื่อนไขที่ควรทดสอบ:
| บริการ | สิ่งที่ควรยืนยัน |
|---|---|
| บริการแปลงสกุลเงิน | จำนวนเงินที่แปลงแล้วเป็นตัวเลขและอยู่ในช่วงที่คาดหวัง |
| บริการคำสั่งซื้อ | สถานะที่คืนมาเป็นหนึ่งในค่าที่อนุญาต |
| บริการสร้างข้อมูล | response มี ID หรือ reference ที่สร้างขึ้น |
จากนั้นสร้าง test scenario ที่เชื่อม request หลายรายการเข้าด้วยกัน เช่น:
CreateOrder → เก็บ orderId → GetOrderStatus → ตรวจสอบสถานะ
อ่านวิธีส่งค่าจาก request หนึ่งไปยังอีก request ได้ที่ เขียนสถานการณ์ทดสอบด้วย Apidog
รูปแบบนี้ไม่ขึ้นกับโปรโตคอล คุณจึงสามารถผสม SOAP call กับ REST endpoint ใน scenario เดียวกันได้
กรณีใช้ WS-Security
SOAP endpoint ที่มีการรักษาความปลอดภัยมักใช้ WS-Security สำหรับการยืนยันตัวตนหรือเข้ารหัสข้อความ
ในกรณีนี้ ให้เพิ่ม block wsse ลงใน SOAP Header ของ XML envelope ตัวอย่างโครงสร้างคือ:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- wsse security block -->
</soap:Header>
<soap:Body>
<!-- operation -->
</soap:Body>
</soap:Envelope>
ขั้นตอนการส่งยังเหมือนเดิม:
- กำหนด
Content-Type - ตั้ง Body เป็น
xml - ใส่ SOAP envelope แบบเต็ม รวม Header ความปลอดภัย
- ส่ง request
- ตรวจสอบ response หรือ SOAP fault
ทำงานอัตโนมัติด้วย Apidog CLI
เมื่อบันทึก request หรือ scenario แล้ว คุณสามารถใช้ Apidog CLI เรียกใช้งานจาก command line เพื่อเชื่อมต่อกับ pipeline ได้
ติดตั้งด้วย Node.js v16 หรือใหม่กว่า:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
รัน test scenario โดยระบุ scenario และ environment:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
ความหมายของ option:
| Option | ความหมาย |
|---|---|
-t |
ID ของ test scenario |
-e |
ID ของ environment |
-r |
reporter เช่น cli, html, junit
|
หากต้องการหลาย reporter ให้คั่นด้วยเครื่องหมายจุลภาค
เอกสารยืนยันว่า Runner สามารถรัน test scenario และ test suite ที่บันทึกไว้ได้ อย่างไรก็ตาม เอกสารไม่ได้ระบุชัดเจนว่า scenario ที่สร้างจากขั้นตอน SOAP สามารถทำงานแบบ headless ได้หรือไม่ ดังนั้นควรตรวจสอบกับโปรเจกต์ของคุณก่อนนำไปใช้กับ CI โดยตรง
ดูตัวอย่างการเชื่อมต่อ pipeline ได้ที่ คู่มือ Apidog CLI CI/CD
คำถามที่พบบ่อย
ควรใช้ Content-Type ใดสำหรับ SOAP request?
ใช้ได้ทั้ง:
text/xml; charset=utf-8
และ
application/soap+xml
โดยทั่วไป SOAP 1.1 ใช้ค่าแรก และ SOAP 1.2 ใช้ค่าหลัง ตรวจสอบ WSDL หรือเอกสารของบริการก่อนส่ง request
ต้องใช้แพ็กเกจแบบชำระเงินเพื่อทดสอบ SOAP ใน Apidog หรือไม่?
ข้อกำหนดที่ระบุคือใช้ Apidog เวอร์ชัน 2.1.31 หรือใหม่กว่า ไม่มีข้อจำกัดเรื่องระดับการใช้งานหรือ self-hosting ที่ระบุไว้สำหรับ SOAP หรือ WSDL
นำเข้า WSDL จาก URL ได้หรือไม่?
เอกสารระบุการอัปโหลดไฟล์ .wsdl และ .xml การนำเข้าผ่าน URL หรือการวางเนื้อหา WSDL ไม่ได้ระบุไว้ ดังนั้นควรอัปโหลดไฟล์
จะทดสอบ SOAP และ REST ในโปรเจกต์เดียวกันได้อย่างไร?
Apidog รองรับ request หลายประเภทภายใน Workspace เดียว คุณสามารถเก็บ SOAP operation, REST endpoint และ GraphQL request ไว้ในโปรเจกต์เดียว และเชื่อมทั้งหมดผ่าน test scenario ได้
หากใช้ GraphQL ด้วย อ่าน ทดสอบ GraphQL API ใน Apidog
WSDL ที่นำเข้าทำให้ request ส่งไปยังเซิร์ฟเวอร์ผิดตัว ต้องตรวจสอบอะไร?
ตรวจสอบ 2 จุด:
- service address ในแท็บ
Environmentsถูกต้องก่อนกดConfirm - เลือก environment ที่นำเข้าจากมุมขวาบนก่อนส่ง request
หาก address ใน WSDL ไม่ถูกต้อง ให้แก้ไขและนำเข้าใหม่ หรือปรับค่า environment ให้ชี้ไปยังปลายทางที่ต้องการ
สรุป
การทดสอบ SOAP ไม่จำเป็นต้องใช้เครื่องมือแยกต่างหากเสมอไป ใน Apidog คุณเลือกได้ระหว่าง:
- ส่ง envelope ด้วยตนเอง: กำหนด
Content-Type, ตั้ง Body เป็นxml, วาง envelope และตรวจสอบ XML response - นำเข้า WSDL: ให้ Apidog สร้าง endpoint และ environment จากไฟล์
ไม่ว่าจะใช้วิธีใด เป้าหมายคือทำให้การตรวจสอบ Web Service ทำซ้ำได้ และยืนยันได้ว่าบริการยังคงปฏิบัติตามสัญญาเดิม
ดาวน์โหลด Apidog เวอร์ชัน 2.1.31 หรือใหม่กว่า นำเข้า WSDL หรือสร้าง SOAP request แรกของคุณ แล้วรวมการทดสอบบริการเก่าเข้ากับ API workflow เดียวกัน
Top comments (0)