Hi all,
Considering the discussions, I have implemented unified response message as
follows.
*Error Response*
{
'error': error message
}
*Success Response*
{
'data' : [ ]
}
In both cases * HTTP status code *is sent in header.
In success response what ever the response
Hi,
@Udara: Noted your points.
@Dakshika: Since the one who makes the API call knows what it is for( APi
endpoints are well defined for their tasks), knowing request is succeeded
will be enough to distinguish.
On Mon, Aug 4, 2014 at 10:39 AM, Udara Liyanage ud...@wso2.com wrote:
Hi,
@Ayesh
Hi,
@Ayesh HTTP status code should be sent as a HTTP header, not in the message
body.
@ Dakshika IMO Jaggery or any client can read the HTTP code from the
response and detect whether it is a success. Then from client side it can
display a success message. AFAIK there is no rule that a success
Hi,
While implementing ES - REST API, since there are several response messages
(both Error and Success) we thought of unifying response messages using a
response-builder.
Then the response message will be a JSON object with following body.
*Error Response*
{
code: ,
message:
}
Hi Ayesha,
I think, we will have to introduce an error: true property when it is an
error. Otherwise there is no way to check whether it is a success or not.
Or do you mean it to be derived from the code property?
On Thu, Jul 31, 2014 at 5:47 PM, Ayesha Dissanayaka aye...@wso2.com wrote:
Hi,
Hi Ruchira,
Yes, idea is to derive the response from 'code' property. 'code' will
consist standard HTTP Status Codes. [01]
Hence, the response on success will always be '2xx'.
[01] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
On Thu, Jul 31, 2014 at 9:04 PM, Ruchira Wageesha
Hi,
How about sending http response code. Then if it is a 200, 201, 204 etc
then it can be considered as the success. Then there is no need of sending
a message like something happens successfully because we can determine it
by response code.
For instance, when a resource with id abc is added
Hi Udara,
Thanks a lot for your suggestions.
As I have mentioned earlier, 'code' is a standard HTTP Status Code.
...idea is to derive the response from 'code' property. 'code' will
consist standard HTTP Status Codes.
Yes, we can drop message property from success response.
Client can
Hi,
IMO we need to have message pram either its an error or success.
because if you take status *202 Accepted* doesn't have mechanism to shows
exact accept scenario in detail. Then we can't go with generic
notification model on frontend and need to write custom implementations on
front end
