2013-10-25 3 views
0

DocuSign은 SOAP 대신 REST API를 사용할 것을 강력히 권장하며 초기 구현시이를 위해 많은 노력을 기울이고 있습니다. 그들은 심지어 새로운 기능이 언젠가는 only be implemented in REST이 될지도 모른다고 제안합니다. 이것은 제 관심사입니다. 어쨌든 우리의 통합을 위해 SOAP API를 사용하는쪽으로 기울어 져 있습니다. 내 기본 질문은 다음과 같습니다.DocuSign API의 REST 및 SOAP 버전을 함께 사용할 수없는 이유는 무엇입니까?

나는 SOAP API에서 내 DocuSign 통합 레이어를 구축 할 것입니다. 내년에 DocuSign은 사실 SOAP 모델을 그대로두고 REST API에서만 새로운 기능을 출시하고 필자는 이러한 기능 중 하나를 필사적으로 사용해야합니다. 모든 SOAP 통합을 그대로두고 REST API를 사용하여 새로운 기능과의 통합을 구현할 수있는 이유가 있습니까? 두 API를 모두 참조하면 배포 규모가 약간 늘어날 수 있지만 위험을 감수 할 수 있음을 이해합니다. 그 외에도, 내가 나란히 사용할 수없는 강력한 이유가 있습니까? 뭔가 망가 뜨릴까요?

답변

2

DocuSign SOAP API와 REST API를 통합하여 사용할 수 있습니다. 실제로 이는 언급 한 정확한 이유에 대한 일반적인 시나리오입니다. 일부 기능은 SOAP에서만 또는 REST에서만 구현되기 때문에 필요한 전체 기능을 사용하기 위해 혼합 된 방식을 사용해야하는 경우가 있습니다.

+0

현재까지 모든 것이 두 API에서 모두 구현되었다고합니다. 당신은 나에게만 구현 된 기능을 가르쳐 주시겠습니까? 이미 기능 세트에 차이가 있다면, 그 차이를 발동시 고려해야합니다. –

+0

여기에 열거 할 차이점이 너무 많습니다. 그러나 SOAP PurgeDocuments 작업과 SOAP ExportAuthoritativeCopy 작업에는 현재 REST API에 해당하는 것이 없습니다. 전체 SOAP API와 전체 REST API를 비교/대조하는 대신, 통합에 필요한 연산을 식별하고 REST에 존재하는 연산 중 어느 것이 존재하는지 1x1을 결정하는 것으로 시작하는 것이 좋습니다. SOAP에서. 이렇게하면 특정 사건에 대해 최선의 결정을 내릴 수 있습니다. –

+0

REST API 가이드 (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf)의 부록 1은 각 REST API 메소드에 해당하는 SOAP API를 보여줍니다. (하지만 참고로 -이 목록에는 두 API의 UNION 만 표시되며 차이점은 표시되지 않습니다.) –