Hey merhabadunyali
I'd suggest the reason why it hasn't been added is that not enough people have requested adding in a payload body to the open source developers on github.
As you already indicated, although not forbidden by the RFCs, some server implementations may not support GET payloads and I suspect it's due to this reason that it's never been added. Adding a payload to a GET might be ok, however most implementations do NOT expect a payload associated with the GET request and so this may cause problems. Essentially most senior devs and architects consider it just bad practice.
From a Software Architect's perspective, it would be a complete anti pattern developing something that is likely to cause problems down the line. There are enough defects in typical software development when coding follows all best practice advice etc., so why borrow trouble by coding a webservice that may have issues later? The cost of fixing those issues, especially if the problems arose when the software was running in live just doesn't equate to a good idea.
There are certain situations when a payload for an equivalent REST request's equivalent JDBC SQL SELECT (data retrieval) is necessary and in these situations you'd again conform with the RFCs. i.e. Use a POST to do the data retrieval if the GET request's URI is too long, or if there are security concerns why you'd want to use a POST rather than a GET.
There are very few genuine reasons when a payload on a GET is really the most effective approach anyway. Typically with a GET you're doing a data retrieval (equivalent to a JDBC SQL SELECT) and so your parameters to filter the query are included in URI. As I mention above, if the URI was too long (so say the WHERE clause of your query had a lot of AND clauses resulting in you hitting the character limit on a URL if doing the query via REST/HTTP), then it'd be tempting to use a payload to handle this. However the RFC's recommend using POST to handle this to maintain the semantics ok.
You mention caching in your post, POST in not an idempotent method, whereas PUT is, so personally if I was coding a webservice with data retrieval in mind and but my URI was going to hit the character limit due to all the AND clauses in my WHERE clause, I'd use the idempotent PUT rather than a POST.
The above is just my opinion and doesn't represent the open source coders of SoapUI. I'm guessing if enough people requested it, then the devs would build it.
I've had several contracts where GET APIs included payloads and other non-advised behaviour and in my experience this happens when the API/webservice has been coded by junior developers that don't really understand HTTP/REST and the webservice was coded without oversight by a senior dev/software architect. On these occasions I contacted a software architect and the developers were told to change their approach to the webservice development.
ta
rich
