Tagged Values

<<RESTAlias>>

<<RESTAdapter>>

Attribute	Description	Allowed Values
alias	Specify the REST alias the adapter should connect to.	a valid REST alias
digestAlgorithm		None	No header generated.
		MD5	Generate header using MD5 algorithm.
		SHA	Generate header using SHA algorithm.
		SHA-1	Generate header using SHA-1 algorithm.
		SHA-256	Generate header using SHA-256 algorithm.
		SHA-512	Generate header using SHA-512 algorithm.

<<RESTInterface>>

This stereotype defines a package as REST interface. It has no additional tagged values.

<<RESTResource>>

<<REST>>

This is what still will be done, if isVerbatimPath is set to true:

variable discovery
The E2E Runtime will try to find and replace variables (:<my variable name>).
colon escaping
If the path contains a colon that (and that does not indicate a path parameter), you can escape this colon by another one, like :: (e.g. /myAPI/resource/aText::anotherText/:variable).
correction of segment delimiters
The E2E Compiler adds a leading slash (if not present), removes trailing slashes (if present) and removes duplicates slashes, e.g. myAPI//resource/:variable/ becomes /myAPI/resource/:variable.

<<RESTParameter>>

<<RESTError>>

<<RESTResponseDefinition>>

REST Adapter Parameters

REST Utility Functions

REST Content Types

With the REST Adapter, the E2E Runtime can handle JSON or XML as content types. The E2E Runtime will parse either response content (JSON or XML) to a response object automatically.
You do not need to set any headers. If no headers are set, the Runtime will use JSON as a default format and set Accept header to application/json,text/json,application/xml;q=0.9,text/xml;q=0.9,*/*;q=0.8.

If you want to control the REST request and response formats, you can set the Content-Type and Accept headers as described on Setting REST Request Options.

Set the Accept header to the content type, you want the REST service to send back as a response.
- application/json for JSON
- application/xml for XML
The E2E Runtime will deduce the Content-Type header accordingly.

This mechanism also works vice versa: setting the Content-Type header and letting the E2E Runtime deduce the Accept header:

Set the Content-Type header to the content type, you want to send to the REST service.
- application/json for JSON
- application/xml for XML
The E2E Runtime will deduce the Accept header accordingly to
- application/json,text/json,application/xml;q=0.9,text/xml;q=0.9,*/*;q=0.8 for JSON
- application/xml,text/xml,application/json;q=0.9,text/json;q=0.9,*/*;q=0.8 for XML
This approach gives the REST service a wider range of content types for sending the response.

Setting the content type headers to any value other than JSON or XML is not supported and the E2E Runtime will throw an exception in this case.

Regarding response parsing, the E2E Runtime will process REST responses as follows:

If the Content-Type header of the response is JSON or XML, respective format will be used (regardless what is specified in the Accept header).
If the Content-Type header of the response is not set, the E2E Runtime will assume that the content matches the Accept header of the request. If no Accept header has been specified, JSON is the fallback.
In case of unsupported Content-Type, JSON is the fallback.
If the log level of the service is set to Debug, the E2E Bridge will log details about unsupported Content-Types to the bridgeserver log. Refer to xUML Service Standard Log for more information on the bridgeserver log.