Skip to content
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

Amberdata adapter - Response different from documentation #1818

Open
aelmanaa opened this issue Apr 22, 2022 · 2 comments
Open

Amberdata adapter - Response different from documentation #1818

aelmanaa opened this issue Apr 22, 2022 · 2 comments

Comments

@aelmanaa
Copy link
Contributor

Hello,

I've tried the following amberdata adapter and noticed that the response is different from what's documented on README file but also different from Ambderdata doc

Request

curl --data '{"id": "1", "data": {"endpoint": "crypto",  "base":"ETH", "quote":"BTC" }}' -H "Content-Type: application/json" -X POST https://<amberdata-adapter-endpoint>

Response

{"jobRunID":"1","result":0.0741599,"maxAge":90000,"statusCode":200,"data":{"result":0.0741599},"metricsMeta":{"feedId":"ETH/BTC"}}

Expectations

Should contain other fields as well:

{
    "timestamp": ..,
    "pair": "ETH_BTC",
    "price": "0.0741599",
    "volume": "..",
    "vwap": ".."
  }
@austinborn
Copy link
Contributor

Hello, thank you for pointing this out, although I believe the adapter is working as expected. The external adapters will always format its own response to the request, so it may not follow the same schema as the response from the data provider's API. In order to get the underlying fields as part of the response in data, you should be able to run the adapter with API_VERBOSE=true as an environment variable. Can you try that out?

@aelmanaa
Copy link
Contributor Author

Hello @austinborn

thank you for your answer. Still the response that I got is different from the what's documented in the README examples .
I'll try with your suggestion.

I understand when you say that the adapter behaves as expected but does it mean that clients have to rely on result rather than other fields? This could be problematic in some cases like AP Election API where important info can be missed. Here we get "result": "271187,Biden" while the client might be interested to know the full name and the party as well.
If this repo is only to raise technical issues then we can close the issue indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants