0

Problem: I'm trying to find a better way to manage changes to several SOAP Clients/Servers that are shared across multiple Web sites (domains/ips). Luckily, I have control of all SOAP servers/clients, but I need to occasionally add a new field or two to some of the complex types.

Adding the fields causes dependency issues to occur across the related sites. Not having the new field in the SOAP server causes errors to occur. Deployments to dev,demo,prod versions of these sites is causing dependency nightmares to occur.

I've seen the way that SugarCRM setup their complex types and noticed that they have lists of name/value pairs. I'm considering taking a similar approach, but wanted to get some feedback from people on Stackoverflow. I'm mainly using PHP/MySQL.

Are there issues with this approach? I thinking that this will allow me to define any number of name/value pairs. I assume it may cause existing issues with the SOAPClient class mapping?

<xsd:complexType name="name_value">
    <xsd:all>
        <xsd:element name="name" type="xsd:string"/>
        <xsd:element name="value" type="xsd:string"/>
    </xsd:all>
</xsd:complexType>

<xsd:complexType name="name_value_list">
    <xsd:complexContent>
        <xsd:restriction base="SOAP-ENC:Array">
        <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:name_value[]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="name_value_lists">
    <xsd:complexContent>
        <xsd:restriction base="SOAP-ENC:Array">
        <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:name_value_list[]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>
hakre
  • 178,314
  • 47
  • 389
  • 754
jjwdesign
  • 3,098
  • 7
  • 34
  • 63

1 Answers1

0

When you make a backward incompatible change you should move the endpoint to a new URL or provide some other sort of marker; in some places, an XML attribute declaring the version required is attached to the first element in band. In others, it's a header included with the HTTP POST request (or more rarely the query string). You then have to account for multiple versions of the API across multiple locations.

As a side note (not trying to start a war here folks): this is where REST architecture really shines: all versioning is handled by MIME types. If an resource cannot support a given MIME type it can signal that fact to the requester and negotiate a more compatible version instead.

jmkeyes
  • 3,653
  • 15
  • 18