[midPoint] Development of the REST API

[Beat Rohrer]

>> - respond with an error code and a message
> Agreed. But the problem is that a short message is often not enough to 
> diagnose a problem. E.g. there might be errors inside an operation, 
> some of the error might be handled, other not, part of the operation 
> was a success and other parts not. As midPoint is using connectors and 
> it communicates with a number of external and really unpredictable 
> systems, midPoint does not always understands what exactly is going on 
> and what's the problem. I cannot really imagine to have a numeric code 
> for every possible error condition in midPoint. Simplistic 
> twitter-like approach will be a step in a good direction and it can be 
> used to divide errors into classes (roughly by existing exception and 
> SOAP fault classes that we already have). It is a good start, but it 
> is not really enough.
>
> We have a partial error and handled error status code for individual 
> operations. As far as I know there is no equivalent in HTTP for that. 
> We have a rich data structure (OperationResult) that is a hierarchical 
> and can describe what exactly was tried and what exactly went wrong. 
> We are placing that in the SOAP faults so a SOAP client can take a 
> full advantage of that. But I have no idea how to do similar thing in 
> RESTful service without turning the service into RPC. Any ideas?
There is indeed no easy solution for this problem in REST. You could 
return a "207 Multi-Status" – but this isn't strictly part of HTTP, 
but defined in rfc4918 for WebDAV (https://tools.ietf.org/html/rfc4918). 
The response's content could consist of a hierarchical array of partial 
results.