3.2.5.9 Executing a Received Invoke Action Request

The directives defined in this section apply when executing a received Invoke Action request, as specified in Invoke Action Request (section 2.2.7.5.1).

The server MUST validate that the HTTP request URI identifies an action exposed by the data service. If this validation fails, a 4xx response code MUST be returned. If the validation succeeds, the server MUST read all required input parameter values from the request body (section 2.2.7.5.1). If any of the parameter values are malformed, a 4xx response code MUST be returned. If the request URI is valid, the server MUST invoke the FunctionImport, as specified in [MC-CSDL], associated with the action by using the parameter values specified in the request URI.

If a FunctionImport requires an input parameter not present either in the request body or as a binding parameter prefix, the server SHOULD pass null for the parameter value to the function. If the parameter type is not nullable, as specified in [MC-CSDL], a 4xx response code MUST be returned.

If the FunctionImport, as specified in [MC-CSDL], is invoked successfully, the return value MUST be serialized according to the syntax rules defined in Invoke Request Types (section 2.2.7.5).

If the Invoke Action request is bound to a resource that does not exist, the server MUST return a 404 response code.

If an Invoke Action request is received in which the action name is not the last segment in the URI path or the action identified is not available on the current resource, the server MUST return a 405 (Method Not Allowed) response code.

If the Invoke Action request includes an If-Match (section 2.2.5.5) header and the request URI binds the action to a resource, the server MUST verify that the bound resource has not changed by comparing its current ETag with the ETag included in the If-Match header. If the resource has changed, the server MUST return a 412 (Precondition Failed) response code, in accordance with the rules specified in [RFC2616].