Page Comparison

...

<api xmlns="http://ws.apache.org/ns/synapse" name="string" context="/string" hostname="string" port="integer">
   <resource/>
</api>

...

name="API_NAME" context="URI_PATH_OF_API" [hostname="HOST_NAME_OF_SERVER"]  [port="PORT_NUMBER"]>
	<resource [methods="GET|POST|PUT|DELETE|OPTIONS|HEAD|PATCH"] [uri-template="URI_TEMPLATE"|url-mapping="URL_MAPPING"]>
	  <inSequence>
        ...
      </inSequence>?
      <outSequence>
         ...
      </outSequence>?
	  <faultSequence>
         ...
      </faultSequence>?
	</resource>
</api>

An API definition is identified by the <api> tag. Each API must specify a unique name and a unique URL context (see below). An 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:

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

Once a request 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.

...

1. In the Management Console, click the Main tab. Then click APIs to open the Deployed APIs page.
2. Click Add API to open the Add API page.
   

   

3. Enter values for the following parameters in the header of the page as required.

   Parameter Name	Description	Data Type	Required/Optional	Best Practices
   API Name	A unique name for the API.	String	Required
   Context	This parameter specifies a URL context to which the requests processed by the REST API should be limited. See Specifying the Context for further information.	String	Required	Version your APIs as early as possible in the development cycle. At present, the ESB identifies each API by its unique context name. If you introduce a version in the API context (e.g., /Service 1.0.0), you can update it when you upgrade the same API (e.g., /Service 1.0.1)
   Host Name	The host at which the API is anchored.	String	Optional
   Port	The port of the REST API.	Integer	Optional
   Add Resource	Click this link to add one or more		At least one resource is required.	Create at most only one default resource (a resource with neither a uri-template nor a url-mapping) for each API. The parameters that can be configured for each resource is described in detail in the next section.

4. Click Add Resource to expand the page and display the Resource section.
   
   Configure the following parameters for the resource.

   Parameter Name	Description	Data Type	Required/Optional
   Methods	Select the required check boxes to indicate the HTTP method to be used to invoke the REST API. See Best practices for designing REST APIs for more information.	boolean	Required
   URL Style	Select a value for his parameter to indicate whether you are specifying a URL mapping or a URI template. A new data field named URL-Mapping or URI-Template will appear based on the selection. Enter the required pattern in this data field.	string	Required
   In Sequence	This specifies the mediation flow for incoming messages. Possible values are as follows. None: Select this to omit the sequence. Define Inline: Select this if you want to define a new sequence and then define the sequence as described in Adding a Mediation Sequence. Pick From Registry: Select this to use an existing sequence saved in the Registry. Use Existing Sequence: Select this to use an existing sequence that already exists in the Synapse Configuration.		One of the four options should be selected.
   Out Sequence	This specifies the mediation flow for outgoing messages. Possible values are as follows. None: Select this to omit the sequence. Define Inline: Select this if you want to define a new sequence and then define the sequence as described in Adding a Mediation Sequence. Pick From Registry: Select this to use an existing sequence saved in the Registry. Use Existing Sequence: Select this to use an existing sequence that already exists in the Synapse Configuration.		One of the four options should be selected.
   Fault Sequence	This specifies the mediation flow for messages with errors. Possible values are as follows. None: Select this to omit the sequence. Define Inline: Select this if you want to define a new sequence and then define the sequence as described in Adding a Mediation Sequence. Pick From Registry: Select this to use an existing sequence saved in the Registry. Use Existing Sequence: Select this to use an existing sequence that already exists in the Synapse Configuration.		One of the four options should be selected.

   Click Update to update the resource to the configuration. Repeat this step to enter as many resources as required.

5. Click Save to save the API. The API would now appear in the list of deployed APIs.

Deleting

...

APIs in the Management Console

The following procedure is used to delete an API.

...

• Use meaningful resource names to clarify what a given request does. A RESTful URI should refer to a resource that is a thing instead of an action. The name and structure of URIs should convey meaning to those consumers.
• Use plurals in node names to keep your API URIs consistent across all HTTP methods.
• Use HTTP methods appropriately. Use POST, GET, PUT, DELETE, OPTIONS and HEAD in requests to clarify the purpose of the request. The POST, GET, PUT and DELETE methods map to the CRUD methods Create, Read, Update, and Delete, respectively. Each resource should have at least one method.
• Create at most only one default resource (a resource with neither a uri-template nor a url-mapping) for each API.
• Offer both XML and JSON whenever possible.
• Use abstraction when it's helpful. The API implementation does not need to mimic the underlying implementation. 
• Implement resource discoverability through links (HATEOAS). As mentioned in the previous section, the application state should be communicated via hypertext. The API should be usable and understandable given an initial URI without prior knowledge or out-of-band information.
• Version your APIs as early as possible in the development cycle. At present, the ESB identifies each API by its unique context name. If you introduce a version in the API context (e.g., /Service/1.0.0), you can update it when you upgrade the same API (e.g., /Service/1.0.1).
• Secure your services using OAuth2, OpenID, or another authentication/authorization mechanism. See also Securing APIs.

...