Quickstart Guide

Web Service Protocols

Melissa cloud services support multiple protocols in order to provide our customers a wide range of technologies to fit into their current architecture. All the protocols allow you to send the same data, and they all return the same data.

HTTP headers need to match the protocols and formats being used. Usually this involves the values of “Content-Type” and “Accept”.

Example JSON Request Header:

{
    "Content-Type": "application/json; charset=utf-8",
    "Accept": "application/json"
}
Last Updated 05/21/2020

XML stands for EXtensible Markup Language. It is an older format than JSON, but still widely used. It was designed to be human-readable, though JSON is both easier to read and faster to use. XML stores information like so:

<key>value</key>
<full_name>John Smith</full_name>

Our web services support XML for both requests and responses, and there are many simple ways to translate back and forth between XML and JSON. Please refer to the documentation of the service for information on the format and structure.

Last Updated 05/21/2020

JSON stands for JavaScript Object Notation. This is a lightweight format for storing and transporting data. Each item is stored as a "key" : value pair.

{
    "key": value,
    "CustomerID": "string",
    "TransmissionReference": int
}

Our web services also support JSON for both requests and responses. Please refer to the documentation of the service for information on the format and structure.

Last Updated 05/21/2020

JSONP stands for JSON with Padding.

JSONP in effect uses JSON objects, but with some additional "padding" that allows cross-domain requests, i.e. it allows requests and responses between domains with different top-level domains, such as a ".com" server talking to a ".net" server.

<script type="application/javascript"
    src="http://server.example.com/Users/1234">
</script>

The URL after "src=" would return a regular JSON object, and the <script…</script> padding would allow it to be received and parsed by, say, server.example.NET.

Last Updated 05/21/2020

REST architecture uses a URL and an HTTP call. This allows you to quickly build a call as a string and submit it with a simple program, or even manually with a browser. REST requests do not support batching, so they are better for real-time checks and testing. Most of our web services allow you to choose a response format from among the previously discussed options.

There are four parts to a REST request.

  1. Endpoint
  2. Method
  3. Parameter
  4. Value

Example REST request:

https://personator.melissadata.net/v3/WEB/ContactVerify/doContactVerify?id=123456&act=Check&a1=22382%20avenida%20empresa&postal=92688&format=JSON

Endpoint:https://personator.melissadata.net
Method:/v3/WEB/ContactVerify/doContactVerify
Delimiter: ?
Parameters & Values:
d=123456
act=Check
a1=22382%20avenida%20empresa
postal=92688
format=JSON
Last Updated 05/21/2020

SOAP stands for Simple Object Access Protocol. It is Ideal for languages with development toolkits like Visual Studio .NET, which makes consuming and using the service very easy. The SOAP protocol can be used for both single record processing and batching.

Please consider using XML when using SOAP. Additionally, since it is an older and slower protocol, not all of our services support SOAP, so we recommend that you use REST, JSON, JSONP, or XML if possible.

Last Updated 05/21/2020