Uploaded image for project: 'SlamData'
  1. SlamData
  2. SD-824

API: clean up and improve error messages

    Details

    • Type: Improvement
    • Status: Done
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 3.0
    • Component/s: Quasar
    • Labels:

      Description

      Currently all errors are returned in a JSON-formatted response of the form {{

      { "error": "..." }

      }}, with a free-form message which looks different and contains different amounts of information for each type of error. In many cases these messages are just taken from the message of some exception or other.

      We should adopt a common style for these messages, and capture useful information as separate fields in the response.

      • [X] Make the value under error an object with at least one field, status.
      • [X] status should contain a fixed text summarizing the problem. These messages should be short, grammatical, capitalized, and end with a period, e.g. "'Destination' header missing."
      • [X] The same status should be used in the HTTP status line, e.g. 400 'Destination' header missing.
      • [X] Any additional detail which may help the user/client to understand the problem should be included as separate fields in the error object, e.g. the text of an unanticipated runtime error message.
      • [X] Where possible, units of data should be captured as separate fields, so that they can be easily captured and used without parsing strings, e.g. "status": "Invalid path.", "detail": "The specified path is not contained within something or other.", "path": "../foo", "targetPath": "/"

      Needing clarity:

      • What exactly constitutes "grammatical"?
      • Should error responses ever include information that's visible in the request (e.g. path in the example above, probably).
      • Is there any need to document the fields, other than in the API tests?

      To implement this cleanly, we probably need a simple, clean abstraction for representing errors to be rendered into this form, and then we need a way to map various kinds of errors that arise in the API services to that form. It will also mean capturing some errors in a way that preserves more detail than we currently have. Also see SD-776 Done .

      Split from SD-759 Done . See discussion on PR SD-821 Done .

        Attachments

          Activity

            People

            • Assignee:
              emrys Emrys Ingersoll
              Reporter:
              mossprescott mossprescott (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: