Common Request Parameters

Overview

Unless otherwise specified within the documentation of a specific service, all services accept a set of common request parameters to control behavior such as obtaining content or specifying how the response is produced. The following table define what these parameters are as well as what they control.

NameValueRequired
(Yes/No)		Usage Notes
uriA valid URINoIndicates location of content.
contentContent to utilizeNoUsed for sending content via parameter.
filter'text', 'html', 'web', 'wp'NoIndicates how content should be processed.
forceFetch'true' or 'false'No Sending the same URI in multiple requests to the system may cause the system to cache the fetched content for a period of time. This optional parameter would instruct the system to ignore the cache and to fetch the page.
format'xml' or 'json'NoSpecifies the format of the body of the response. Default: 'xml'. Some services support formats other than XML and JSON and documentation for the service will indicate the other formats it supports.
externalIdUp to 1024 characters.No Caller provided data that will be returned in the 'about' section of the response.
externalMetadataUp to 1000 charactersNo Caller provided data that will be returned in the 'about' section of the response.

Indicating Content:

All SemanticHacker API services require the request to 'indicate' content. This can be done in several ways. First, the request can include a URI as a parameter to direct the service to a particular document. Of course this URI must be publicly accessible so that our servers can view it. Another option for short content is to assign a parameter named 'content' to the content value you wish the service to process. And lastly you can send the content in the body of an HTTP request. You may use POST, PUT, and multi-part file upload request styles. For a more detailed specification of HTTP requests, see our HTTP Request Reference.

Content and URI Rules:

If both a URI and a content parameter or content upload are used in a single request the API will return an error. If both a content parameter and a content upload are sent, the value of the content parameter will be appended to the request body, prefixed by a new line.

Configuration IDs:

Many of services also allow for an optional configuration ID to be provided at the end of the request path. For example, the URL path http://api.semantichacker.com/TOKEN/signature/odp_2009_l1_1.6k would return a Semantic Signature® created from our 'Open Directory Project' based semantic dictionary that has 1.7 thousand semantic dimensions. Visit the Service Configurations page to view all currently available service configuration IDs.

Filter Parameter:

The filter parameter indicates how the indicated content will be handled before being used by the Semantic Signature® technology. See the documentation on the 'filter service' for detailed information on how to use this parameter effectively.