Oracle WMS Cloud Request Example (key-value pairs)

Using the POSTman Google Chrome extension, here's a sample HTTP request:

Request example

Request example

You can see from the screenshots that we have:
  1. A request verb of POST
  2. A URI (URL) of http://xxxxxxxxxxxxxxx/dummy_endpoint/test
  3. An Authorization header (I had put in a username/password and POSTman encrypted it for me)
  4. A Content-Type header of "application/x-www-form-urlencoded", which tells us that the data in the request body will be key-value pairs:
    1. Even though you don't see this explicitly in the headers screenshot above, it will be present in the actual request shown below
  5. 4-data keys with corresponding values in the request body: first_name, last_name, gender, and extra_data

When we convert this request from the POSTman UI to HTTP:

Request example

This is the request information that is actually transmitted!

  1. It tells HTTP that we want to POST a request to the host xxxxxxxxxxxx for resource /dummy_endpoint/test using HTTP version 1.1
  2. It also shows that we have the request headers Authorization, Cache-Control, Postman-Token, and Content-Type:
    1. You don't need to worry about Cache-Control or Postman-Token
  3. It is shows the request body data as key-value pairs represented in the format discussed
    1. This is expected since the Content-Type is set to "x-www-form-urlencoded"
  4. Finally, we can see that it encoded the illegal ñ character to "%C3%B1" for transmission
    1. %C3%B1 is the UTF-8 representation of ñ

Request Example (XML)

In this example, we will have the same setup as the previous one except that instead of key-value data, we will be sending the XML message:
<Person>
 <FirstName>Jane</FirstName>
 <LastName>Doe</LastName>
 <Gender>female</Gender>
 <ExtraData>ñ</ExtraData>
</Person>

Using the POSTman Google Chrome extension, the following HTTP request was created:

Request example

You can see from the screenshots that we have:

  1. A request verb of POST
  2. A URI (URL) of http://xxxxxxxxxxxxxxxxxx/dummy_endpoint/test
  3. An Authorization header (I had put in a username/password and POSTman encrypted it for me)
  4. A Content-Type header of "application/xml", which tells us that the data in the request body will be XML
  5. An XML message in the request body

When we convert this request from the POSTman UI to HTTP:

  1. It tells HTTP that we want to POST a request to the host xxxxxxxxxxxxxxxx for resource /dummy_endpoint/test using HTTP version 1.1
  2. It also shows that we have the request headers Authorization, Cache-Control, Postman-Token, and Content-Type:
    1. You don't need to worry about Cache-Control or Postman-Token
  3. It is shows the request body XML data:
    1. The XML has been encoded for transmission since characters like "<" and ">" are illegal for HTTP

Notice that the data is the same as before, just represented in an XML format that was made up for this example.

This is done to show that the same data can be passed via many different methods and formats using web services.

What's most important is that the two communicating system agree on these details up front so that each system knows what to expect.