Usage of /v1/resource_provider/request_transaction API

[eguller]

Hello,
I have scenario, but I am not sure whether /v1/resource_provider/request_transaction is the right API to use.
Let’s say there are 3 accounts,
sender - One of our customers, customer has private key, customer creates and signs the transaction and send us, we just execute API requests and do internal accounting.
recipient - Same as sender, just another customer. In this case sender will send some amount of EOS to recipient.
payer - This is our account used by our application. We have the private key. We use this account to create other customer accounts like sender, recipient etc…

We want to abstract away implementation details of EOS like CPU, RAM, NET. sender sends 10 EOS to recipient and recipient has 10 EOS in this account.

I tried to use resource_provider/request_transaction API.
1.
If I get this response from resource_provider API

{
  "code": 400,
  "message": "Network resources not required by this account.",
  "data": {}
}

I proceed with push_transaction . (Since we are delegating some small amount of CPU and NET when we create accounts.)
2.
In case of 200, can I execute this transaction as is, after the verification?
Or should transaction be signed again by client (in this case sender).

I was confused about this paragraph

With the modified transaction verified to match what is expected, the application can either create a signature themselves for this new transaction or relay the transaction to the end user for signature in their preferred wallet. Once the user has signed this modified transaction, it can be broadcast to the blockchain and the resource provider will cover the costs.

In following article

Initial specification for the Resource Provider API endpoint

With a formal EEP draft for Resource Providers underway, I decided to take a bit of time today to write up a post containing the specification of the primary API we have designed, both to explain the process and start gathering feedback. This post will be technical, so if you are a non-technical user, following may be difficult. The take away for you however should be that progress is being made on what is known as Resource Providers (like Fuel) to give both free and paid transactions to users …

So what does it mean “application can either create a signature themselves”. In this case since we do not have the private key of sender, how can we sign ? And relaying to user also not possible for our case, because this is one way flow in our application. (So let’s say client has a mobile device, and transaction can be created and signed by mobile device, server cannot push a transaction to mobile device to be signed.)

3.
In case of 402, we want to pay fee from payer’s account which we have the private key. Can we sign this modified transaction with payer private key and execute so all costs are deducted from payer’s account ?

I checked this example, so my understanding it is not possible and sender should sign again modified transactions which are returned by /v1/resource_provider/request_transaction

https://gist.github.com/aaroncox/d74a73b3d9fbc20836c32ea9deda5d70#file-fuel-core-presign-js-L177-L181

[aaron]

@eguller

We want to abstract away implementation details of EOS like CPU, RAM, NET. sender sends 10 EOS to recipient and recipient has 10 EOS in this account.

I tried to use resource_provider/request_transaction API.

The request_transaction endpoint isn’t needed if you’re including and paying for the transaction. That endpoint is only used if you’re requesting someone else to pay for it. So if you’re signing with a payer, you can omit that step and just use your account to pay for it (or setup your own API to serve that endpoint).

@eguller

In case of 200, can I execute this transaction as is, after the verification?

If you get a 200, it should be good to use as-is, so long as you verify its the transaction you want to perform.

@eguller

So what does it mean “application can either create a signature themselves”. In this case since we do not have the private key of sender, how can we sign

This was simply a way of saying your app could sign it with a private key directly, or you could send the transaction to a users wallet (Anchor, etc) so they could sign it.

@eguller

In case of 402, we want to pay fee from payer’s account which we have the private key. Can we sign this modified transaction with payer private key and execute so all costs are deducted from payer’s account ?

The response from the API is always going to bill the first authorizer of the transaction. So if you want to use the API service and the transaction it returns, make sure the first authorizer is the one you want paying.

It sounds like you’re trying to use the request_transcation endpoint as well as pay for resources yourself - which I think my first answer kinda outlined is not required. You’d use the request_endpoint transaction only if you want that API endpoint to pay for the transaction. If you want to pay for the transaction yourself, you wouldn’t use this API endpoint at all - you’d just make sure you’re the first authorizer and then sign it.

Hope that helps!