Allow for easier overriding of contact URL in API error response messages #285
Labels
Comments
GUI
added a commit
to NREL/api-umbrella-gatekeeper
that referenced
this issue
Sep 18, 2015
Now there's a concept of "common" error data variables, which we can use so that contact URLs (and other things like this) only have to be defined once per API backend, which makes it much easier to define variables only once which can then be embedded in other areas of the error response. See: 18F/api.data.gov#285 This also begins to cleanup and standardize the error data variables to snake_case moving forward (instead of some of our odd mixtures of camel-case that had built up over time).
GUI
added a commit
to NREL/api-umbrella-web
that referenced
this issue
Sep 18, 2015
The https error data was added a while ago, but we forgot to expose customizing it via the admin UI. This is now addressed. See: 18F/api.data.gov#285 Related to changes made on the gatekeeper in 6d2e6574998ff0478481d7ff7f0b327019006e05
GUI
added a commit
to NREL/api-umbrella-router
that referenced
this issue
Sep 19, 2015
This is part of 18F/api.data.gov#285 The associated changes are on the gatekeeper project's 6d2e6574998ff0478481d7ff7f0b327019006e05 commit.
This was referenced Sep 19, 2015
|
The coding of this should be done. This touches each api umbrella component, so here are the associated pull requests: NREL/api-umbrella-gatekeeper#21, NREL/api-umbrella-web#24, NREL/api-umbrella-router#8. But I'm going to wait to merge this and deploy the changes until I have a bit more time and a better internet connection (so probably this weekend or early next week). |
|
These changes are now live. This should now give us an easier way to document the suggested setup in #277. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This stems from this issue: #277 As noted there, when setting up API backends, an administrator can customize the error responses returned by api.data.gov for things like invalid API keys, over rate limits, etc. Most of these error messages usually contain a contact link (since we want to give the user an easy pointer of who to contact if they're encountering any errors).
The main issue with the current implementation is that it's not particularly easy to override just the contact URL Instead you have to overwrite the full message body for each type of possible error if you want to place a custom contact URL in the message. This doesn't make it very conducive to having admins update their contact links in these error messages.
To fix this, what I'd propose doing is adding a concept of "common error data" within the API backend configuration. Within this area, you could then define a
contact_urlvariable with your URL. This is similar to how the other error data variables work, but this new "common" error data would apply across all error types (rather than specific errors like over rate limit vs api key missing). From there, we can update our default messages to use thecontact_urlvariable in the message bodies. This should simplify things quite a bit so that an admin only has to update this single variable and all messages will be updated with their own contact link. This will also make it a lot easier to document the recommended processes for agencies.The text was updated successfully, but these errors were encountered: