Q: what are the params?
You should move the params explanation lower to here.
Also note what's mandatory

So i think in the overview its enough to state the format of the endpoint and the detailed explanation down where it is, do you think thats fine or should I move it all to this section?
Also I have chosen this classic REST format, which differentiates from the way etherscan and blockscout has implemented their endpoints, entirely with query parameters, not sure if thats gonna affect the user. Do they expect the exactly same format
In etherscan the ednpoints look like this:

GET /api
   ?module=account
   &action=tokentx
   &contractaddress=0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2
   &address=0x4e83362442b8d1bec281594cea3050c8eb01311c
   &page=1
   &offset=100
   &startblock=0
   &endblock=27025780
   &sort=asc
   &apikey=YourApiKeyToken

Acceptance tests should be in teh form of E2E features a User would go through with a focus on the input and the outputs

Edited them : )

How so, please expand

+1 on this. Please expand on how ERC Registry is involved.

+1 on this. Please expand on how ERC Registry is involved.

Can we call out the cached objects. I'd like to ensure that we only cache what is needed e.g. in some cases the relay caches the full account or token object but we really only need a few fields from the mirror node response.
In this case do we need to cache a full log or can we cache only a subset of them?

No, we dont need to cache the full object, so I changed and specified what we will need

Please suggest an TTL for these caches components.

Done

We currently have a max on the logs endpoint we can likely match that

Currently, investigating this. Seems like its 100 so added this as a value @Nana-EC

I don't see a section for this, could you add one that calls out which config fields you plan to add and what their defaults might be?

I added one :) Its a starting point tho, maybe something comes up later during implementation

Hmm, another approach would be rest-server package with the controllers under there and the services under the relay package or this new rest-api package.
In this way the service implementation could be change in the future a transparent way or the underlying server logic - both packages decoupled from each other.
Let's chat about it, the above is food for thought and might hint towards the final form we want to get to in a tentative refactor of the repo

I will add it as a point to discuss in the meeting

You should note that initially we'll use the static outputs from the smart contract repo. We should be able to import that package soon but int eh early stage we can copy over the files as needed

changed

I wonder if we should make the etherscan nature explicit
Somethings like what snowtrace does https://testnet.snowtrace.io/documentation/api-swagger

@Nana-EC I get what you mean, but I think their design is like this because they have different networks available. And will we have something else than etherscan, imo it may be confusing to have it like this, since we may also want to redesign the endpoint format in the future.

That's why having a unique oath would be preferred. I that way the etherscan support approach can be left alone and a future version that we designed with better REST principles could be added with my conflict

I do agree with Nana.

Please take a look at
https://api-testnet.snowtrace.io/api?module=contract&action=getsourcecode&address=0x5425890298aed601595a70AB815c96711a31Bc65, a user may use this when looking for ABI
I think this might be another goal to capture. P2 in nature for this story though.
This is very interesting as it may require calling the verification service.

@acuarica do you see any other option to retrieve such information?

No, the verification service is the source of truth when getting the ABI.

Does it makes sense to call it Etherscan token Controller?
an alternative is to create it inside folder called etherscan. There could be other proxy apis in the future

I name it token controller, since I plan it will be responsible for all the endpoints from the token module but i may put it into etherscan folder

Imagine we implement etherscan and snowflake. Same controlles for both, or separated ( folder/ naming)? what will the approach?
Personally Iam used to split to find easierm group things. Whats the usual approach here?

What are the restrictions at etherscan side?

they say "This API endpoint returns a maximum of 10000 records only." which is lees, because we are talking a about transactions (records)

I suggest to have the same limits if possible

Not quite sure what you mean. In etherscan 10000 records limit is for this endpoint, which we are not going to implement. The limit i mentioned here is for this one,
https://docs.blockscout.com/devs/apis/rpc/account#get-token-transfer-events-by-address, where they have limit for 10000 blocks

Do you see the limit in code? I am not able to see it on the doc. Only
Up to a maximum of 10,000 token transfer events. Also available through the GraphQL token_transfers query.

no really seeing 10k blocks limit

I do agree with Nana.