News / Technology

A common cause of confusion, especially for newly hatched developers, is the one-lettered distinction between URL and URI.

In the world of Mulesoft the term used to designate URL parameters, also known as URL query strings, is QueryParams. URL stands for Uniform Resource Locator. It contains information about a resource's location and may refer to a web page, a downloadable file, an e-mail address, etc.

QueryParams are a part of the URL. Their start within a URL is denoted by the question mark. Different QueryParams are separated by the ampersand (&) sign. QueryParams always come in key-value pairs.

URI, which stands for Uniform Resource Identifier, is a set of characters (a short string) used to identify a resource. In theory and on paper many things can be considered a resource, but for all practical purposes within the Mulesoft context, a URI identifies something unique by its name or value at a specified location in the URL.

A URI is a part of a URL but, unlike URL parameters or QueryParams, a URI parameter does not appear as a key-value pair in a URL and cannot be recognized instantly. At the first glance, URI parameters within URLs look like a file path of folders and subfolders separated by a slash. This is because only the value part is show in in the URL.

QueryParams are specified in the URL. An HTTP Listener in a Mule application will recognize and save them as attributes in the Mule message. Since URI parameters do not appear as key-value pairs in the URL, the key part as well as the URI parameter location within the URL must be specified in advance in the corresponding RAML file.

Then, after an HTTP Request is sent by a web client, the value will be assigned to the key, according to the RAML specification. The value can be accessed in Anypoint Studio through the attributes.