[oslc-core] Question/remarks about error responses

Thunissen Marc marc.thunissen at oce.com
Mon Oct 17 01:44:07 EDT 2011


Hello Steve,

Thank you for your reply.
I am trying to clarify my ideas and you already give interesting suggestions.

I think we may have to provide several levels of response.

First, this is an API, so we need a short machine-readable response to guide the client software.
The oslc:statusCode is of this kind.
But there may be so many reasons to issue an HTTP 400.

A second level of information should be a small human readable message (maybe only in English or in the language of the server) that the client software can display (this can help in case the client software need to be better configured) or log in a file.

The oslc:message seems to be this level.

A third level could often be necessary to provide details about the error, such as:
 - the line number and column where the xml parser found something bad
 - the name of the attribute with a bad value
 - may be the posted content
I don't like using the oslc:moreInfo URL to provide such information: this could be too big to fit in an URL and this mean that a second call must be performed to get a readable display.

I think there is a need for an embedded String or XMLLiteral property in the Error resource to provide details about the error.
For now I will add my own extension but I think I would be better to normalize this.

Best regards,

Marc

-----Original Message-----
From: Steve K Speicher [mailto:sspeiche at us.ibm.com] 
Sent: jeudi 13 octobre 2011 22:26
To: Thunissen Marc
Cc: oslc-core at open-services.net
Subject: Re: [oslc-core] Question/remarks about error responses

Hello,

Response below...

> From: Thunissen Marc <marc.thunissen at oce.com>
> To: <oslc-core at open-services.net>,
> Date: 10/12/2011 04:20 AM
> Subject: [oslc-core] Question/remarks about error responses Sent by: 
> oslc-core-bounces at open-services.net
> 
> Hello,
> 
> I am a little bit disappointed about the definition of the Error and 
> ExtendedError resources definition.
> 
> I would like to be able to return brief and understandable error
messages, 
> and in some case I also need to provide more information to help the 
> diagnose on the OSLC client.
> 
> I can use the oslc:Error.oslc:message property for the understandable 
> message but I can’t find a place for the additional information.
> The oslc:ExtendedError.oslc:moreInfo is defined as a resource to 
> provide
“by
> reference”.
> This means that another REST request must be issued to get the this
information.
> So I must keep the details of the error somewhere on the server !?
> But, by definition, REST does not allow this.
The idea is not to store the state/session information for the request's error but perhaps respond with a URL to a form (with fields to fill in the from included in the URL).  For example, if there is a failed creation of a resource (POST), then the POST'd content could be encoded into the URL for a web form.

> So what should I do ?

What additional information are you needing to provide to a client?

I'd say that you can just simply add to the oslc:Error definition the additional items you need within your own namespace.  If there are things that you need and believe they need to be part of the spec, please outline what is needed to be considered.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.

If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.

Thank you for your co-operation.


More information about the Oslc-Core mailing list