Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Representational State Transfer (REST) provides a lightweight approach for building distributed systems. Instead of relying on overly complicated protocol stacks and heavyweight middleware, REST facilitates communication between systems by leveraging simple message formats and open protocols that power the Web. This section introduces the fundamentals of working with REST APIs. It illustrates the concepts through the XML configuration. For information on adding an API through the Management Console UI, see Adding APIs in the Management Console

Defining an API

An API definition is identified by the <api> tag. Each API must specify a unique name and a unique URL context (see below). A REST API is made of one or more resources, which is a logical component of an API that can be accessed by making a particular type of HTTP call. For example:The syntax of a REST API is as follows.

Code Block
languagexml
<api name="StringAPI_NAME" context="uri path of URI_PATH_OF_API" [hostname="host name of serverHOST_NAME_OF_SERVER"]  [port="port numberPORT_NUMBER"]>
	<resource [methods="GET|POST|PUT|DELETE|OPTIONS|HEAD|PATCH"] [uri-template="uri templateURI_TEMPLATE"|url-mapping="url mappingURL_MAPPING"]>
		<inSequence>  <inSequence>
        ...
      </inSequence>?
		<outSequence>
      <outSequence>
         ...
      </outSequence>?
		<faultSequence>  <faultSequence>
         ...
      </faultSequence>?
	</resource>
</api>

Once a request An API definition is identified by the <api> tag. Each API must specify a unique name and a unique URL context (see below). A REST API is made of one or more resources, which is a logical component of an API that can be accessed by making a particular type of HTTP call. For example:

Code Block
languagexml
<api name="API_1" context="/order">
    <resource url-mapping="/list" inSequence="seq1" outSequence="seq2"/>
</api>

Once a r//equest is dispatched to a resource it will be mediated through the in-sequence of the resource. At the end of the in-sequence the request can be forwarded to a back-end application for further processing. Any responses coming from the back-end system are mediated through the out-sequence of the resource. You can also define a fault-sequence to handle any errors that may occur while mediating a message through a resource.

...