L'API SOAP si aspetta un elemento stringa?

Question

L'API SOAP si aspetta un elemento stringa?

#1 da (2 voti)
#2 da (0 voti)

1

Ultimamente ho interagito con una manciata di API SOAP di diversi sistemi aziendali e sono un po 'perplesso che spesso i WSDL sembrano indicare che dovrebbero ricevere dati XML come una "stringa". Ad esempio, un WSDL indica che il servizio prevede dati conformi al seguente snippet di XSD per alcune operazioni:

...
<s:element name="PostSomeData">
  <s:complexType>
    <s:sequence>
      <s:element minOccurs="0" maxOccurs="1" name="Data" type="s:string"/>
    </s:sequence>
  </s:complexType>
</s:element>
...
<wsdl:message name="PostNewhireRecordSoapIn">
  <wsdl:part name="parameters" element="tns:PostSomeData"/>
</wsdl:message>
...

Quando in realtà il contenuto del tag Data stesso deve contenere qualche XML, di solito con caratteri di escape o come Dati carattere ( <![CDATA[<SomeStructuredData>...</SomeStructuredData>]]> ) che aderisce ad uno schema che può essere o non essere fornito.

Cosa dà? Perché c'è una propensione per le API da progettare in modo tale che i webservices SOAP si aspettino xsd: string? Sembra che. se userò SOAP, dovrei descrivere la struttura dell'XML previsto piuttosto che definire il webservice come se si aspettasse una stringa di XML .

web-services web-api soap

posta Thomas Matecki 02.05.2017 - 05:16

fonte

2 risposte

0

Potrei sbagliare leggermente sui dettagli storici, ma credo che originariamente, SOAP fosse stato progettato per funzionare come un sistema RPC (Remote Procedure Call). Definirebbe un servizio come se fosse una funzione in un linguaggio di programmazione procedurale, con argomenti e tipi di ritorno, ad es. function foo(string arg1, int arg2) returns string .

Solo una manciata di tipi primitivi erano definiti dagli standard core, ma ci si aspettava che quelli più complessi fossero dichiarati come parte della definizione del servizio usando WSDL, XSD, ecc. Da una prospettiva RPC, l'input e l'output non erano mai XML , era un insieme di strutture dati che erano state trasportate su XML.

In pratica, tuttavia, strutture di dati complesse sono molto difficili da rendere portatili, quindi è stato più semplice trattare il documento XML come input e output e lasciare che i processori su ciascuna estremità decidano come elaborare quel documento. Questo porta allo stile "documentale / letterale" dell'utilizzo di SOAP, in cui l'input e l'output sono definiti come documenti XML completi, non un insieme di parametri di input e output.

Tuttavia, molti strumenti di integrazione SOAP aziendale sono ancora costruiti attorno al concetto RPC e quindi non si prestano al modo di lavorare "documentale / letterale"; potrebbero richiedere una definizione di servizio complessa per capire che i tipi "reali" sono "serializzati" nel documento XML. Per ovviare al problema, le persone creano un servizio RPC SOAP che prevede e restituisce stringhe singole e quindi trasporta i documenti XML completi come stringhe opache.

Ciò consente allo sviluppatore di riutilizzare il componente SOAP del loro framework per gestire il trasporto e una gestione di base degli errori, quindi definire il loro vero servizio come XML in, XML out.

Al massimo, tale servizio può utilizzare la busta SOAP come un wrapper standardizzato per l'autenticazione, la gestione delle sessioni, ecc; nel peggiore dei casi, aggiunge semplicemente un sovraccarico su HTTP che non sarebbe necessario se SOAP non fosse mai esistito.

risposta data 02.05.2017 - 16:35

fonte

Leggi altre domande sui tag web-services web-api soap

Se una fabbrica crea sempre un nuovo oggetto Framework over-HTTP basato su eventi

score 2 · Accepted Answer

Normalmente questo non è un buon design. Non c'è molto di un contratto è tutto il servizio è: "inserisci stringa gigante qui".

Il WSDL dovrebbe definire un contratto che è esplicito tra il chiamato e il chiamante. Se tutto il contratto è un formato stringa indefinito, sarà difficile e complicato da utilizzare.

Tuttavia, a volte ciò è necessario se il servizio è un passaggio o sta memorizzando il contenuto della chiamata di servizio secondaria all'interno del payload.

Non conosco il contesto della tua situazione, ma potrebbe esserci una buona ragione per questa implementazione.

Di solito, questo è un tentativo errato di estendere il servizio senza modificare lo schema perché la stringa può essere qualsiasi cosa, quindi il contratto WSDL ufficiale non cambia mai.