SOAP 엔드포인트를 받으셨습니다. 아마도 청구팀이 여전히 의존하는 레거시 통화 변환기이거나, 파트너가 .NET으로 운영하는 주문 관리 웹 서비스일 수 있습니다. 이를 호출하여 계약에서 약속한 내용을 반환하는지 확인하고, 주변 코드가 변경되어도 올바르게 유지되는지 입증해야 합니다. REST 도구는 SOAP가 전체 XML 엔벨로프, 특정 Content-Type, 그리고 모든 작업을 설명하는 WSDL을 요구하기 때문에 잘 맞지 않습니다.
Apidog은 REST, GraphQL, gRPC와 함께 SOAP 및 웹 서비스 요청을 처리하므로, 스택에 있는 단 하나의 레거시 서비스를 위해 별도의 앱이 필요하지 않습니다. 이 가이드는 두 가지 문서화된 경로를 안내합니다: SOAP 요청을 수동으로 전송하는 방법과 Apidog이 환경 및 엔드포인트를 구축할 수 있도록 WSDL을 가져오는 방법입니다. 더 넓은 프로토콜 개요를 먼저 원하시면, REST, GraphQL, gRPC, SOAP 비교가 각 프로토콜이 어떤 위치에 있는지 설명합니다. 엔벨로프 구조의 공식적인 정의는 W3C SOAP 사양이 권위 있는 출처입니다.
SOAP란 무엇이며, 왜 다른 처리가 필요한가
Apidog은 SOAP를 다양한 플랫폼과 프로그래밍 언어가 서로 통신할 수 있게 해주는 XML 기반 통신 프로토콜인 Simple Object Access Protocol로 설명합니다. 이 한 가지 아이디어가 왜 그렇게 많은 기업이 여전히 이를 사용하는지 설명해 줍니다. Java 클라이언트와 .NET 서비스는 서로의 내부 구조에 신경 쓰지 않고도 동일한 계약을 통해 통신할 수 있습니다.
테스트할 때 세 가지 속성이 중요합니다. SOAP는 메시지 형식 지정에 XML을 사용하므로, 모든 요청과 응답은 느슨한 JSON 덩어리가 아니라 구조화된 문서입니다. XML 자체가 익숙하지 않다면, MDN의 XML 참조가 읽고 쓸 구문에 대한 확실한 입문서가 될 것입니다. 프로토콜이 다른 것을 지원하더라도 일반적으로 HTTP 또는 HTTPS를 통해 전송됩니다. 그리고 구조화되고 신뢰할 수 있는 통신을 위한 W3C 표준을 따르므로, 메시지 형태가 엄격하고 유효성 검사 규칙이 확고합니다.
이러한 엄격함은 SOAP 엔드포인트가 플랫폼 간 통합, 레거시-현대 브리지, 그리고 암호화되고 인증된 메시징을 위한 WS-Security를 사용하는 보안 트랜잭션을 위해 계속 사용되는 이유입니다. 또한 REST 스타일 요청을 단순히 보낼 수 없는 이유이기도 합니다. 올바른 헤더, SOAP 엔벨로프에 래핑된 XML 본문, 그리고 반환되는 XML을 읽는 방법이 필요합니다. 엔벨로프와 그 본문이 데이터를 전달하는 방법에 대해 더 자세히 알아보려면 SOAP API와 XML에 대한 설명을 참조하십시오.
시작하기 전에
아래 모든 내용을 시작하기 위한 한 가지 필수 요구 사항이 있습니다. SOAP 또는 웹 서비스 요청을 보내려면 Apidog 버전이 2.1.31 이상이어야 합니다. 이전 빌드에서는 지원하지 않습니다. Apidog을 열어 버전을 확인하고, 최신 버전이 아니라면 업데이트하십시오. 이 가이드의 다른 모든 내용은 사용자가 2.1.31 이상 버전을 사용하고 있다고 가정합니다.
아직 Apidog이 없다면, Apidog을 다운로드하여 따라 해보십시오. 무료로 사용해 볼 수 있으며, 신용카드 정보가 필요 없습니다.
또한 대상 서비스의 세부 정보(엔드포인트 URL, 호출하려는 작업 이름 및 해당 매개변수)를 준비해야 합니다. WSDL 파일이 있다면 가까이에 두십시오. 이 가이드의 후반부에서 직접 가져오기 때문입니다.
경로 A: SOAP 요청을 수동으로 보내기
이는 엔드포인트가 있고 호출하려는 작업을 아는 경우의 경로입니다. REST 요청에는 필요 없는 세 가지를 설정해야 하며, 이를 올바르게 설정하는 것이 전체 작업입니다.
1단계: Content-Type 헤더를 수동으로 설정하기
SOAP 요청은 자체 헤더를 추론하지 않습니다. Content-Type을 직접 설정하며, 두 가지 유효한 값이 있습니다:
text/xml; charset=utf-8application/soap+xml
어떤 것이 올바른지는 서비스에 따라 다릅니다. SOAP 1.1 엔드포인트는 일반적으로 text/xml; charset=utf-8을 기대하고, SOAP 1.2 엔드포인트는 종종 application/soap+xml을 원합니다. 확실하지 않다면 WSDL 또는 서비스 문서를 확인하고, 첫 번째 값이 콘텐츠 유형에 대한 오류를 반환하면 다른 값으로 전환하십시오. 요청을 보내기 전에 요청의 헤더 섹션에 헤더를 추가하십시오.
2단계: 본문 형식을 XML로 설정하고 엔벨로프 붙여넣기
요청 본문 형식을 xml로 설정한 다음 SOAP 엔벨로프를 붙여넣으십시오. 엔벨로프는 네임스페이스 선언과 호출하려는 작업, 그리고 그 안에 중첩된 모든 매개변수를 포함하는 Body 요소를 가진 문서입니다.
다음은 Apidog이 문서에 사용하는 것과 동일한 형식의 공개 숫자-단어 변환 서비스에 대한 예시입니다. 작업은 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>
작업의 네임스페이스는 서비스가 예상하는 것과 일치해야 합니다. 그래서 추측하기보다는 WSDL에서 읽어야 합니다. soap:Body는 실제 호출을 감싸고, web:NumberToWords는 작업이며, web:ubiNum은 입력입니다.
3단계: XML 응답 보내고 읽기
요청을 보냅니다. 응답은 XML 형식으로 반환되며, Body에 응답 작업이 포함된 SOAP 엔벨로프입니다. 위의 호출에 대해 결과가 중첩된 NumberToWordsResponse를 받게 됩니다:
<?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>
응답은 요청을 반영합니다: 작업 이름에 Response 접미사가 붙고, 값은 결과 요소에 들어갑니다. 이 반영된 내용에 대해 검증을 수행합니다. 엔벨로프가 돌아왔는지, NumberToWordsResponse 노드가 존재하는지, 그리고 결과가 예상한 것과 일치하는지 확인합니다. 두 번째 예시를 원하시면 webservice.apidog.io의 Apidog 전용 웹 서비스 문서에 전체 구성 참조와 더 많은 샘플 엔벨로프가 있습니다.
현실적인 사용 사례도 동일한 세 단계를 따릅니다. 레거시 환율 서비스의 NumberToWords를 ConvertCurrency 작업으로 바꾸고, fromCurrency, toCurrency, amount를 중첩 요소로 전달한 다음, 응답 엔벨로프에서 변환된 수치를 읽어옵니다. 또는 주문 웹 서비스에서 GetOrderStatus 작업을 호출하고, orderId를 전달한 다음, 반환된 상태 노드를 검증합니다. 메커니즘은 변하지 않습니다: 헤더, XML 본문, 전송, 엔벨로프 읽기.
경로 B: 엔드포인트 생성을 위해 WSDL 가져오기
엔벨로프를 수동으로 입력하는 것은 한 번의 호출에는 괜찮습니다. 서비스가 수십 개의 작업을 노출할 때는 WSDL이 작업을 수행하도록 하십시오. WSDL 파일은 모든 작업, 해당 입력 및 서비스 주소를 설명하며, Apidog은 이 모든 것을 한 번의 가져오기로 읽어들입니다.
정확한 클릭 경로는 다음과 같습니다:
- 설정으로 이동한 다음, 데이터 가져오기를 선택합니다.
WSDL을 선택합니다..wsdl또는.xml파일을 업로드합니다.- Apidog이 파일에서 파싱한 API 엔드포인트 미리보기를 검토합니다.
환경탭을 열고 서비스 주소가 올바른지 확인합니다.확인을 클릭합니다. 가져온 환경이 자동으로 생성됩니다.- 오른쪽 상단 모서리에서 가져온 환경을 선택합니다.
- 요청을 보냅니다. 기본 URL은 해당 환경에서 자동으로 적용됩니다.
해당 목록에서 두 가지 단계는 사람들이 건너뛰고 나중에 후회하는 부분입니다.
WSDL의 서비스 주소가 가져온 모든 요청이 도달할 엔드포인트이기 때문에 5단계가 중요합니다. 만약 WSDL 작성자가 업데이트하지 않은 스테이징 호스트나 플레이스홀더 URL을 가리킨다면, 요청이 잘못된 곳으로 전송됩니다. 확인을 클릭하기 전에 환경 탭에서 이를 확인하십시오. 클릭한 후가 아닙니다.
기본 URL이 자동으로 생성된 환경에 있기 때문에 7단계가 중요합니다. 오른쪽 상단 모서리에서 가져온 환경을 선택하지 않으면, 요청에 기본 주소가 없어 실패합니다. 먼저 선택한 다음 전송하십시오.
가져오기가 완료되면 각 작업은 엔벨로프를 직접 작성하지 않고도 호출할 수 있는 엔드포인트로 나타나며, 경로 A에서와 마찬가지로 XML 응답을 검증합니다. 다른 도구에서 전체 프로젝트를 옮기는 경우, SOAP 프로젝트 가져오기 가이드가 마이그레이션을 처음부터 끝까지 다룹니다.
한 가지 솔직한 제한 사항을 참고하십시오: WSDL 가져오기는 .wsdl 및 .xml 파일의 파일 업로드에 대해 문서화되어 있습니다. URL을 통해 WSDL을 가져오거나 내용을 붙여넣는 것은 문서화되어 있지 않으므로, URL 필드를 기대하기보다 파일을 업로드하십시오.
SoapUI에서 전환하기
현재 SOAP 테스트가 SoapUI에 있다면, 빈 페이지부터 다시 만들 필요가 없습니다. WSDL을 내보내거나 보관한 다음, 경로 B를 사용하여 Apidog으로 가져오면, 설계, 목업, 문서화도 수행하는 작업 공간 내에서 호출 가능한 엔드포인트로 동일한 작업을 사용할 수 있습니다. 얻는 이점은 통합입니다: 별도의 도구에 분산시키는 대신 하나의 프로젝트가 SOAP 서비스, REST 엔드포인트 및 테스트 시나리오를 모두 포함합니다. Apidog 대 SoapUI 비교는 무엇이 계승되고 워크플로가 어떻게 다른지 설명합니다.
어설션 및 변형
단 한 번의 성공적인 호출은 엔드포인트가 활성화되어 있음을 증명합니다. 테스트는 그것이 올바르다는 것을 증명합니다. SOAP 요청이 반환되면 응답 엔벨로프에 어설션을 추가하십시오: 예상되는 응답 작업 노드가 있는지 확인하고, 결과 요소를 추출하며, 해당 값을 계약이 약속하는 것과 비교하여 확인하십시오. 통화 서비스의 경우 변환된 금액이 범위 내의 숫자인지 확인하고, 주문 서비스의 경우 상태가 허용된 값 중 하나인지 확인합니다.
거기서부터 호출을 연결하는 반복 가능한 테스트 시나리오를 구축할 수 있습니다. 예를 들어, 주문을 생성하고, 그 상태를 조회하며, 단계 사이에 값을 전달할 수 있습니다. Apidog으로 테스트 시나리오 작성하기에 대한 가이드는 추출된 값을 후속 요청에 연결하는 방법을 보여줍니다. 이 패턴은 프로토콜에 구애받지 않으므로, 시나리오는 SOAP 호출과 주변의 REST 엔드포인트를 혼합할 수 있습니다.
보안 엔드포인트의 경우, SOAP는 암호화되고 인증된 메시징을 위해 일반적으로 WS-Security를 사용합니다. 해당 보안 헤더는 전송하는 SOAP 엔벨로프의 일부이므로, wsse 보안 블록을 작업과 함께 엔벨로프의 헤더 내부에 추가합니다. 전송 메커니즘은 동일하게 유지됩니다: Content-Type을 설정하고, 보안 헤더를 포함한 전체 엔벨로프를 XML 본문에 넣고 전송합니다.
Apidog CLI로 워크플로 자동화하기
SOAP 또는 WSDL 가져오기 요청이 테스트 시나리오로 저장되면, Apidog CLI는 명령줄에서 이를 실행하여 파이프라인이 모든 푸시에서 테스트를 수행할 수 있도록 합니다. Node.js v16 이상으로 설치한 다음 인증하십시오:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
WSDL 가져오기에서 생성한 환경에 대해 ID로 저장된 시나리오를 실행하십시오:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
여기서 -t는 테스트 시나리오 ID이고, -e는 환경 ID이며, -r은 리포터(여러 개일 경우 쉼표로 구분된 cli, html, junit)입니다. 한 가지 솔직한 주의사항: 문서에는 러너가 저장된 테스트 시나리오와 스위트를 실행한다고 확인되어 있지만, SOAP 단계로 구축된 시나리오가 헤드리스로 실행되는지는 명시되어 있지 않습니다. 따라서 CLI를 프로젝트의 HTTP 시나리오와 CI에서 WSDL로 가져온 엔드포인트를 동기화하는 엔진으로 사용하고, SOAP별 실행을 가정하지 마십시오. 파이프라인에 연결하는 방법은 Apidog CLI CI/CD 가이드에 설명되어 있습니다.
자주 묻는 질문
SOAP 요청에는 어떤 Content-Type을 사용해야 합니까? text/xml; charset=utf-8 또는 application/soap+xml 중 하나입니다. 올바른 것은 서비스에 따라 다릅니다: SOAP 1.1 엔드포인트는 일반적으로 첫 번째 것을 기대하고, SOAP 1.2 엔드포인트는 두 번째 것을 기대합니다. 요청 헤더에서 수동으로 설정하고, 콘텐츠 유형 오류가 발생하면 다른 값으로 전환하십시오.
Apidog에서 SOAP를 테스트하려면 유료 플랜이 필요합니까? 유일하게 문서화된 요구 사항은 Apidog 버전이 2.1.31 이상이어야 한다는 것입니다. SOAP 또는 WSDL 지원에 대한 계층 제한이나 자체 호스팅 제한은 명시되어 있지 않으므로, 현재 버전으로 업데이트하면 됩니다.
URL에서 WSDL을 가져올 수 있습니까? 문서화된 WSDL 가져오기는 .wsdl 및 .xml 파일의 파일 업로드를 허용합니다. URL을 통해 WSDL을 가져오거나 WSDL 텍스트를 붙여넣는 것은 문서화되어 있지 않으므로, 파일을 업로드하십시오. 가져오기 후, 환경이 자동으로 생성되며, 전송하기 전에 오른쪽 상단 모서리에서 해당 환경을 선택합니다.
동일한 프로젝트에서 SOAP 및 REST API를 모두 테스트하려면 어떻게 해야 합니까? Apidog은 이들을 하나의 작업 공간 내의 요청 유형으로 처리하므로, 단일 프로젝트에 REST 엔드포인트 옆에 SOAP 작업, 심지어 GraphQL 호출까지 포함할 수 있습니다. GraphQL도 다루고 있다면, Apidog에서 GraphQL API 테스트하기 가이드가 해당 부분을 다루며, 테스트 시나리오는 이 모든 것을 아울러 요청을 연결할 수 있습니다.
WSDL로 가져온 요청이 잘못된 서버에 도달했습니다. 무슨 일입니까? 두 가지 일반적인 원인이 있습니다. 환경 탭의 서비스 주소가 가져오기 시점에 잘못되었는데 확인하지 않고 확인을 클릭했거나, 오른쪽 상단 모서리에서 가져온 환경을 선택하지 않아 기본 URL이 적용되지 않았기 때문입니다. 다시 가져와서 주소를 확인한 다음, 전송하기 전에 올바른 환경이 활성화되어 있는지 확인하십시오.
마무리하며
SOAP 테스트가 별도의 레거시 도구를 의미할 필요는 없습니다. Apidog에서는 엔벨로프를 수동으로 보내거나(Content-Type 설정, 본문을 XML로 설정, 엔벨로프 붙여넣기, XML 응답 읽기) WSDL을 가져와 Apidog이 엔드포인트와 환경을 구축하도록 할 수 있습니다. 두 경로 모두 동일한 결과에 도달합니다: 웹 서비스가 계약을 여전히 준수하는지 반복적으로 확인할 수 있습니다. 버전 2.1.31 이상의 Apidog을 다운로드하고 WSDL을 가져와 레거시 서비스를 나머지 API 표면과 동일한 테스트로 관리하십시오.