-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update with intake forms #1
base: master
Are you sure you want to change the base?
Conversation
use `fields` instead of `response_fields`
@@ -1,4 +1,5 @@ | |||
import fetch from "node-fetch"; | |||
import { TOKEN_ENDPOINT } from "./../api_urls.js"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the primary purpose of this code is to serve as a document to communicate how to call the API, I think overt code is preferable, even if duplicative.
@@ -0,0 +1,6 @@ | |||
const API_VERSION = "v1"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API versioning is per-module, so it will make more sense, I think, to include it as part of the opaque string that makes up the base url. It is very likely that the version numbers will increment differently for each API. The Auth API will likely never increment, but if we introduce a breaking change in the Vendor API, we would not need to increment all API versions nor deprecate URLs for other modules.
The TOKEN_ENDPOINT
itself is a special case, as that is the name given in the OAuth2 specs, in that it is an opaque value to callers of the API that hopefully they would just paste into their OAuth2 client libraries that manage token expiration and renewal for them.
This is following @ayudemura 's work in https://gitlab.com/vendorful/app/-/merge_requests/2477
Creating examples for intake form public API GET and POST.