1. About Web Services
        1.1 What is a Web Service?
        1.2 What is XML?
        1.3 What is SOAP?
        1.4 What is REST?
        1.5 Do you have a DTD available for the XML WebSmart Web Service (DQWS2)?
        1.6 Why are there two web service options? DQWS and SOAP and which do I need?

2. When and Why Use Web Services
        2.1 What can the WebSmart Web Service (DQWS2) do for my company?
        2.2 What are some common applications of our WebSmart Web Service (DQWS2)?
        2.3 When should I choose a locally based programmers tool (Address Object) or a Web service
              based address solution?
 

3. Technical Information
        3.1 What type of performance can I expect with the WebSmart Web Service (DQWS2)?
        3.2 What server architecture and what type of redundancy is in place with this Web Service?
        3.3 I'm worried about the security of my data. Can you provide me with a secure solution?       
        3.4 Where can I get sample code to submit data to the WebSmart Web Service (DQWS2)?   
        3.5 I think my SOAP header might be incorrect. What should my SOAP header look like?
 

FAQs
 

1. About Web Services

1.1 What is a Web Service?

A Web service is a software application whose interfaces are capable of being defined, described, and discovered in the XML language. A Web service supports direct interactions with other software using XML based messages exchanged via standard Internet-based protocols.

1.2 What is XML?

eXtensible Mark-up Language, a specification developed by the W3C. XML is a pared-down version of Standard Generalized Mark-Up Language, designed especially for Web documents. XML is a universal format for structured documents and data on the Web.

1.3 What is SOAP?

SOAP is an acronym for Simple Object Access Protocol and is a standards based exchange protocol for the discovery and implementation of web services with XML. SOAP is a current web service standard and behind it stands industry heavyweights such as Microsoft and IBM ™.

1.4 What is REST?

REST stands for Representational State Transfer. It conforms to the WC3 Web Services Architecture. A REST request is a simple HTTPS request containing parameters in the URL Query. The response returned is in XML format and is identical to the results returned by our XML service. REST was considered an alternative web service implementation to SOAP and XML, until recently where its popularity has significantly grown.
 

1.5 Do you have a DTD available for the XML WebSmart Web Service (DQWS2)?

There is no DTD available. Due to the fact that you can send just the tags you require, the use of a DTD is not applicable since we would have to create a DTD for every possible permutation of tag selections. However our new SOAP interface is provided with a WSDL document for clear definitions of all functions of the service.

1.6 Why are there two web service options? DQWS and SOAP and which do I need?

Since Melissa Data is at the forefront of innovative technologies, we released our DQWS web service before any industry standards had been finalized. The DQWS web service is very easy to utilize from any language and platform. Those installations using .NET or the various SOAP toolkits and requiring a WSDL, would be better served with our new improved SOAP interface. Also many enhancements to the SOAP web service have been implemented, like Residential Delivery Indicator, and street search matching options.

2. When and Why Use Web Services

2.1 What can the WebSmart Web Service (DQWS2) do for my company?

By scrubbing and enhancing your important customer data you maximize and increase the quality of your bottom line. We know that your most important asset is your customers and making sure they are reachable for your invoicing or direct mail campaigns is critical. There are no updates to install as the service is online, real-time, and headache free.

2.2 What are some common applications of our WebSmart Web Service (DQWS2)?

Real-time address verification from web forms or call centers so that the address is verified at the point of entry. Also now with the SOAP interface we support batch lookups for your complete address verification needs.

2.3 When should I choose a locally based programmers tool (Address Object) or a Web service based address solution.

Those customers that require high security and maximum batch processing performance will wish to implement a local solution like our COM objects. Real time entry of data from a website or call center is the perfect use of the web based solution.

3. Technical Information

3.1 What type of performance can I expect with the WebSmart Web Service (DQWS2)?

This solution is in real-time so each individual record sent from your site to ours is corrected and enhanced on the spot. Depending on factors such as bandwidth, routing and traffic there will be some fluctuation. However the normal times usually hover between one to two seconds per record.

3.2 What server architecture and what type of redundancy is in place with this Web Service?

Our web servers run Windows 2003 and utilize load balancing so incoming requests are sent immediately to the next available server. Melissa Data provides monitoring and real time testing of all servers so that any problems will be flagged and technicians notified. This design allows for no single point of failure and helps ensure high availability for your critical data.

3.3 I am worried about the security of my address data. Can Melissa Data provide me with a secure solution?

HTTPS is a secure version of the HTTP Protocol and is available as an option for those customers who require an extra layer of security.

3.4 Where can I get sample code on how to submit data to the WebSmart Web Service (DQWS2)?

Whether you just signed up for our free trial or if you are an existing customer we will make code available on request. Currently we have sample code available in VB.net ASP.net, Perl, PHP, C++ and C#.

Click here for the sample code.

 

3.5 I think my SOAP header might be incorrect. What should my SOAP header look like?

In order to make a request to the web services, the appropriate headers must be set in order to correctly communicate with the correct web service.

Here is an example of what a well formed header looks like:

POST /v2/SOAP/Service.svc HTTP/1.0
Content-Length: 4267
Host: addresscheck.melissadata.net:443
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:MelissaDataAddressCheckService/IService/doAddressCheck"

Take note that if any of the information above is missing from your header (POST, Content Length, HOST, Content Type or SOAP Action), the SOAP request will fail and return an error. It is important that a proper header be sent in order to make a proper request.

In order to figure out what the actual header looks like as it sent out, you can use tools that will sniff packets from your server. There are free tools online, such as Wireshark, which you can download and install, allowing you to sniff packets from your server and view the SOAP Header in your request. This will allow you to grab the actual packets and let you see if the request header being send is valid and properly formatted.