| do/4 | Equivalent to do(Url, Contract, Request, Id, [], []). |
| do/6 | Equivalent to do(Url, Contract, Request, Id, HTTPOptions, Options, true). |
| do/7 | Send an atom/tuple RPC call request to a JSON-RPC service at Url. . |
do(Url, Contract, Request, Id) -> any()
Equivalent to do(Url, Contract, Request, Id, [], []).
do(Url, Contract, Request, Id, HTTPOptions, Options) -> any()
Equivalent to do(Url, Contract, Request, Id, HTTPOptions, Options,true).
do(Url::string(), Contract::atom(), Request::atom() | tuple(), Id::string(), HTTPOptions::proplist(), Options::proplist(), SubstAuthInfoP::bool()) -> {ok, term() | undefined, term() | undefined, string()} | {error, term()}
Send an atom/tuple RPC call request to a JSON-RPC service at Url.
Per JSON-RPC definition, if we return an +ok+ 4-tuple, either the
2nd element will be +undefined+ (i.e. call failed, see 3rd element) or the
3rd element will be +undefined+ (i.e. call succeeded, see 2nd element).See the Inets app docs for http:request/4 for definition of HTTPOptions
and Options arguments.If the SubstAuthInfoP flag is true, then the 2nd element of the
Request tuple is assumed to be authentication info of some kind.
It must be agreed upon that the contract is expecting such auth
info games, because the server side will extract auth info from the
HTTP session and insert that data into the 2nd element of Request,
which will effective replace whatever the client had placed in the
2nd element here on the client side.