I havent actually used the OAuth v1.0 config settings, but if a specific field in ReadyAPI! requires a URL then im guessing that these fields are defined in the rules as resolvable....i.e. you need these values from remote servers (im guessing its very similar to OAuth v2.0 which i have used before now)
Just so youre aware, its a bit of a fallacy to compare Postman to ReadyAPI! for certain things and im guessing this is one of those things. As another example: the RFCs describing the different http methods/verbs that can be exercised in a REST request define a GET request as synonymous with an SQL SELECT request and doesnt include a payload. The RFC even suggests changing the method to POST if a payload is needed. ReadyAPI! doesnt by default support including a payload with a GET request (im guessing cos of what the RFC says), whereas Postman does support adding a payload to a GET request because the functionality in the tool isnt as tightly coded/constrained as ReadyAPI!
N.b. Smartbear recently provided a config change that enables a payload field for a GET, but this is not the default config setting.
I suggest you read up on OAuth functionality and the back and forth processing that occurs. This will allow you to understand/appreciate why certain fields are URLs.
What im suggesting is that the ReadyAPI! functionality is actually working "as required" but youre misinterpreting how it should actually work.
Offend me? Youll have to try a lot harder than that fella.....in fact, most people that know me would say im pretty much unoffendable!
I appreciate that you want the tool to be able to exercise your requirements but if youre not using the tool in the method the RFCs and other supporting sources proscribe (when the tool has been coded to comply with those RFCs) then you can hardly blame the tool!
The fact that youre developers have just given you strings to input to help you out, just doesnt work in this situation. The OAuth functionality is configured for your to obtain those values yourself...which is how id suggest most people would need the functionality to behave.
I should highlight that you can still exercise apis using OAuth without using the OAuth functionality cos ive had to do this before myself (similar situation to you....my project didnt provide me with what i needed) so i setup the individual REST calls of the back and forth processing of the OAuth myself.