You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Think this is a minor thing, or is intended behaviour so can discard issue if it's not something to be dealt with.
When you create an OOB invitation you are allowed by the endpoint to specify just one (or neither, or both) of goal and goal_code.
Supplying neither, or both returns an invitation block that represents the request.
However if you only supply one of those, the API call treats as a valid request, and a 200 response. But the one you supplied does not end up in the response.
Maybe only supplying 1 does not make sense from a business requirements usage? Or maybe it should be allowed?
But just from a REST request/response pattern, to me at least, I think it could cause confusion to the caller that one of those is supplied but then missing.
Could 422 if you only supply 1 of them, if it's indeed a requirement that you must require neither or both.
The text was updated successfully, but these errors were encountered:
The OOB RFC 434 specifies that both fields are optional and does not ever say both are required. A goal without a goal_code makes very little sense, although I wouldn’t say the same for the reverse. That matches what @wadeking98 was doing — providing the code so that BC Wallet knows what to do, and providing an empty string for the goal because, who cares?
I would say that we keep the current behaviour in ACA-Py (both required if used) and update the RFC to clarify if either are needed, both must be provided — even it the value of goal is an empty string.
From discussion in comments here #2583
Think this is a minor thing, or is intended behaviour so can discard issue if it's not something to be dealt with.
When you create an OOB invitation you are allowed by the endpoint to specify just one (or neither, or both) of
goal
andgoal_code
.Supplying neither, or both returns an invitation block that represents the request.
However if you only supply one of those, the API call treats as a valid request, and a 200 response. But the one you supplied does not end up in the response.
Maybe only supplying 1 does not make sense from a business requirements usage? Or maybe it should be allowed?
But just from a REST request/response pattern, to me at least, I think it could cause confusion to the caller that one of those is supplied but then missing.
Could 422 if you only supply 1 of them, if it's indeed a requirement that you must require neither or both.
The text was updated successfully, but these errors were encountered: