Ich persönlich mache um
den REST-Client einen großen Bogen und erstelle mir einen Client für eine REST-
API 
nach folgendem Schema.
Den internen Http-Client kann man auch noch abstrahieren und per Injection hineingeben. Dann wird es komplett testbar und ist offen für jede Http-Library die morgen dann der Hype ist.
Ich finde es immer wieder interessant, wie viele Wege es gibt um ein Problem anzugehen
Prinzipiell mache ich genau das selbe. Nur dass ich zwei Ebenen tiefer ansetze und eine Klassenstruktur gebaut habe, die sowohl mit
XML als auch JSON und einem proprietären Format umgehen und die einzelnen Nodes über einen simplen XPath ansprechen kann. So habe ich dann auf der Anwendungsebene eine einheitliche Schnittstelle, egal ob der Server nun REST oder
SOAP spricht. Die Kommunikationsebene könnte ich eigentlich auch beliebig austauschen.
Ich habe es jedoch auch mit Bestandscode zu tun, der über eine lange Zeit gewachsen ist und entsprechend bunt ist das Angebot an verwendeten Schnittstellenkomponenten. Und in dem Fall hat mich und die Kollegen diese TRESTClient-Komponente viel Zeit gekostet, weil sie keine Exceptions auf HTTP-Protokollebene wirft und der Server in dem beschriebenen Szenario mehr oder weniger kommentarlos die Verbindung verworfen hat (bei
Indy das bekannte Connection closed gracefully). Und wieso Emba hier bei Windows < 10 nur die älteren Transportverschlüsselungen aktiviert obwohl die neueren verfügbar sind, das muss mir auch noch jemand erklären.