REST services in general return errors via the HTTP status code, so first of all, you should carefully choose the status code you are returning on a service call. Besides the HTTP status code there is no standard way of how to provide additional error information with REST service implementations. Developers can return additional information in HTTP headers or body, though.With the Bridge REST implementation, we decided to provide error information via the HTTP body by an error class or a Blob.
Defining Errors in the REST Service Interface
Default Error ClassEach REST port type should have a default <<RESTError>> class assigned. The Bridge will use this class as a default output in case of error.Figure: Example REST Error ClassIn case of error, this class should befilled with some error information andassigned to the REST HTTP response (so the error information will be returned to the caller)The xUML Runtime will recognize attributes as error code and/or error message under the following conditions:if you applied the names code and/or message to these attribute(s)if you applied the stereotypes <<RESTErrorCode>> and/or <<RESTErrorMessage>> to these attribute(s)In this case, Runtime error codes and/or messages will automatically by assigned to these attributes in case of error.Refer to Implementing REST Operations for more information on error handling.Specific Error ClassesYou can define specific error classes for specific HTTP errors to provide more information on the error, or just return a Blob.Figure: Specific Error Class Use this feature carefully. Having multiple error responses will possibly make your service confusing and will make it harder to implement service calls for a potential client.There is no difference between using an error class or a Blob. Assign the specific error class to related operations or REST resources via a <<use>> dependency having stereotype <<RESTResponseDefinition>>.Figure: Assigning Error Class to REST OperationsOn these <<use>> dependencies, you have to specify an HTTP status code on the name tag. For this status code, the default error class will be overwritten by the specific class.You cannot overwrite HTTP response codes using REST Parameter classes (like e.g. 200).You can apply the following name templates:Example NameDescription401A specific status code.The specific error class will only be used, if exactly this HTTP status code is send back.40?, 4??Defining a status code pattern.The specific error class will only be used, if the HTTP status code that is send back matches the pattern.???All status codes.This pattern defines a new default error class for the resource or operation. The specific error class is valid for all HTTP status codes.The definitions above are reflected in the OpenAPI service description (see (25.3) Defining a REST Service Interface#REST Response Definitions).Response definitions using patterns (like e.g. 40? or 4??) can not be generated to the OpenAPI file, so it is not recommended to use them. A response definition having pattern ??? will be generated as default response of the operation. Refer to (25.3) Defining a REST Service Interface#REST Response Definitions for more information on this.For responses of type Blob, you can additionally specify a blob body content type on the <<RESTResponseDefinition>> (tag blobBodyContentType). This information will be generated to the OpenAPI descriptor file and will set the the "Content-Type" header to this content type. Default content type is "application/octet-stream".Refer to Implementing REST Operations for more information on error handling.
Implementing Error Handling
Each REST port type should have a <<RESTError>> class assigned. The Bridge will use this class as output in case of error (see Defining a REST Service Interface).In the support manager example, REST port type SupportAPI has class RESTError assigned as error class. 
