#89 Option to pass backend service errors through


Peter suggested that it would be useful if, when using API-A Lite, if a backend HTTP service gives a non-200 response, instead of having Fedora return a generic 500 error, it returned the exact error code and payload that the backend service returned.

In practical terms, this would simplify debugging by passing the ultimate error straight through.

Dan and I talked about this and believe it's appropriate to retain the ability to hide the cause of the error (in effect, to have Fedora intercept the error, log it, and provide a unique event id for later lookup by an authorized user). In a production environment, it may not be appropriate to provide back-end service error detail to the agent making the dissemination request from Fedora.


  • Chris Wilper

    Chris Wilper - 2007-10-03

    Logged In: YES
    Originator: YES

    Reasons it may not be appropriate to configure Fedora this way in production:
    - security (exposing sensitive infrastructure details to the outside world)
    - encapsulation (don't want clients to Fedora to be dependent on backend service impl details)

  • Peter Murray

    Peter Murray - 2007-10-03

    Logged In: YES
    Originator: NO

    I like the idea of an interceptor to log and return a unique event id back to the caller. This would seem to imply a structured, well-defined form of an error entity body that would be returned by Fedora in the event of such a non-2xx response code from the disseminator.

    One downside might come in the form of a client that is not behaving RESTfully. A client that tried to parse the entity body without looking at the response code to see if the request succeeded or failed would likely choke. But, then again, they would choke now anyway...

  • Chris Wilper

    Chris Wilper - 2007-10-05
    • assigned_to: nobody --> datagazetteer
  • Daniel Davis

    Daniel Davis - 2008-09-15
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks