Don't require Pair and ExtrinsicParams trait bound for getter implementations.

[clangenb]

We always require Pair or ExtrinsicsParams for all the Api implementations. This leads to the weird situation, where an actual pair needs to be supplied even if we never set a signer, as we don't need to sign anything, e.g.:

substrate-api-client/examples/get_blocks.rs

Line 31 in 7ff294c

let api = Api::<sr25519::Pair, _, AssetTipExtrinsicParams>::new(client).unwrap();

If we remove the trait bound for all getters, we can instantiate the Api like this, which is much simpler:

let api =  Api::<(), _, ()>::new(client).unwrap()

[haerdib]

The Pair problem should be solved with PR #356. The ExtrinsicParams will need to be solved in a separate PR

[haerdib]

There's one problem with ExtrinsicParams: extrinsic_params_builder needs to be of type Params::OtherParams:

substrate-api-client/src/api/api_client.rs

Line 96 in 7e5962b

extrinsic_params_builder: Option<Params::OtherParams>,

So simply moving the function to a different impl will not solve this.

I see the following options:

1. Empty impl of ExtrinsicParams. See Do not require extrinsic params #410
2. Do not return ExtrinsicParams. Instead let the Api implement the trait to return additional_signed and signed_extra:
   

   substrate-api-client/primitives/src/extrinsic_params.rs

   Lines 74 to 81 in 7e5962b

   	/// These are the parameters which are sent along with the transaction,
   	/// as well as taken into account when signing the transaction.
   	fn signed_extra(&self) -> Self::SignedExtra;
   	/// These parameters are not sent along with the transaction, but are
   	/// taken into account when signing it, meaning the client and node must agree
   	/// on their values.
   	fn additional_signed(&self) -> Self::AdditionalSigned;

   
   Drawback: There will be no "independent" extrinsic parameter struct anymore.
3. Restructure the Api: Let not the api hold the values of runtime_version, metadata and such, but instead the ExtrinsicParams themselves. This way, the ExtrinsicParams value would need to be set, not the Params::AdditionalParams, allowing to remove the trait enforcement.

What's your take on that @clangenb ?

[clangenb]

I don't like 1. and 2., but 3. is an option for me, but it goes against the initial goal to be able to have () in the api-client as we still want to have runtime-version and metadata.

Maybe just separate the api into:

GetterClient
ExtrinsicSender
FullApiClient

Or lastly, perhaps we should just combine the all those fields into Config struct, where we can also supply one that works for default chains usually similar to subxt.

[haerdib]

If we separate, then I believe two are enough. The ExtrinsicSender needs to be able to get things as well. At least to know its nonce. Therefore, I'd vote for GetterClient and FullApiClient. Three would just complicate the matter.

Hm.. maybe yes to the Config struct. But maybe both make sense, as the GetterClient would be a lot simpler than the FullApiClient, not needing any node information at all.

If it's alright with you, I'll create a follow-up issue with a GetterClient creation and close this one. The Config issue already exists.

[clangenb]

This is ok for me, however, my ideas were just a brainstorm, take it with a grain of salt.

[haerdib]

Don't worry. I was thinking about that as well. And I think subxt has a similar concept with offline and online client.

[haerdib]

Closing this issue in favour of #432 and #406