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
{{ message }}
This repository has been archived by the owner on Mar 24, 2020. It is now read-only.
At the moment, the Aeon::Request and to a somewhat lesser extent Aeon::Queue are hiding the Aeon properties that are being returned from the various API calls.
The Request API call, for example, returns a json hash with over 40 properties. And as far as I can tell, there only about 4 actually used:
id (transactionNumber)
email (comes from a separate API call to get the user data)
itemTitle
transactionStatus
It would be nice to have a more firm, explicit contract with the API as to the expectations of what fields the application is using, and what format we expect the values for those properties to be in.
One way we could do this, at least for Request, is to replace the Hashie::Mash setup with the ValueSemantics gem: https://github.com/tomdalling/value_semantics Personally I would be a big fan of this approach, and would feel more comfortable carrying it forward into a future dams system.
Rationale
The Aeon API is very new, and has already exhibited problems in dealing with batch requests, and therefore seems relatively likely to break our assumptions about the data we're getting back at some point in the future. The Hashie::Mash current solution works quite well, but if the API changes, we would get more useful, direct feedback if we had a more explicit contract w/ the API.
The text was updated successfully, but these errors were encountered:
Descriptive summary
At the moment, the
Aeon::Request
and to a somewhat lesser extentAeon::Queue
are hiding the Aeon properties that are being returned from the various API calls.The Request API call, for example, returns a json hash with over 40 properties. And as far as I can tell, there only about 4 actually used:
It would be nice to have a more firm, explicit contract with the API as to the expectations of what fields the application is using, and what format we expect the values for those properties to be in.
One way we could do this, at least for Request, is to replace the
Hashie::Mash
setup with the ValueSemantics gem: https://github.com/tomdalling/value_semantics Personally I would be a big fan of this approach, and would feel more comfortable carrying it forward into a future dams system.Rationale
The Aeon API is very new, and has already exhibited problems in dealing with batch requests, and therefore seems relatively likely to break our assumptions about the data we're getting back at some point in the future. The
Hashie::Mash
current solution works quite well, but if the API changes, we would get more useful, direct feedback if we had a more explicit contract w/ the API.The text was updated successfully, but these errors were encountered: