That status code does seem appropriate - I guess there could be a question
as to whether we should provide a code outside rfc2616 but it certainly
would be more informative than 400 (and some of the other rfc4918 codes
could be useful in the future if we supported full transactioning and any
locking capabilities outside the current optimistic concurrency support).
The REST API documentation doesn't in fact in general specify error codes
(apart from setDatastreamVersionable) and I believe most of the integration
tests just test for a failure.
So would this in fact constitute an API change to move away from 500 to eg
422 for invalid FOXML (and for the new object validation failure)? My
preference would be to go for this in 3.6, clearly documenting it in the
release notes.
Steve
-----Original Message-----
From: aj...@virginia.edu [mailto:aj...@virginia.edu]
Sent: 27 January 2012 16:31
To: fedora-commons-developers@lists.sourceforge.net
Subject: Re: [fcrepo-dev] Fedora validation enhancements - FCREPO-1026
Whether or not we can (or want to) do this for 3.6, I agree that a
400-series error is more appropriate here, since the system is able to
respond correctly and the problem is at a different semantic level than the
HTTP protocol.
Perhaps a 422 (Unprocessable Entity)? Unfortunately, this is a WebDAV
extension, but the semantics very good for this case. See:
http://tools.ietf.org/html/rfc4918.
The 422 (Unprocessable Entity) status code means the server understands the
content type of the request entity (hence a 415(Unsupported Media Type)
status code is inappropriate), and the syntax of the request entity is
correct (thus a 400 (Bad Request) status code is inappropriate) but was
unable to process the contained instructions. For example, this error
condition may occur if an XML request body contains well-formed (i.e.,
syntactically correct), but semantically erroneous, XML instructions.
---
A. Soroka
Software and Systems Engineering
Online Library Environment
the University of Virginia Library
On Fri, Jan 27, 2012 at 5:20 AM, Stephen Bayliss
<stephen.bayl...@acuityunlimited.net> wrote:
<snipped>
* HTTP response code for REST API operations: Currently if an ingest fails
XML validation this is reported via HTTP status code 500 (Server Error). To
maintain consistency with the existing behaviour, object validation failures
will also result in this code, with the text of the exception containing
details of the validation failure. I'd suggest that maybe 400 - Bad Request
[1] might be more appropriate for both of these; but this would essentially
represent a REST API change - would that be acceptable for a Fedora 3.6
release? If this change was made I'd suggest implementing this by catching
ObjectValidityException at the API level, and extending this exception to
contain details of the validation failure for the response body (rather than
the 500 exception reporting that occurs currently).
<snipped>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
