Basiert TRESTClient WIRKLICH auf Indy?

[Codehunter]

Hallo!

Ich bin seit einiger Zeit über eine Aussage in der Emba-Doku zu den REST-Komponenten verwirrt:

Zitat:

TRESTClient ist so konzipiert, dass alle HTTP-bezogenen Exceptions so lange verborgen werden, wie die Exception durch HTTP-Standardcode dargestellt werden kann. Der Client löst nur "harte" Exceptions aus, wie z. B. fehlende Clientbibliotheken bei einer TLS/SSL-Verbindung, Verbindungsfehler usw. Das Framework arbeitet mit den bekannten Komponenten von Indy (Internet Direct). Unter Sichern von Indy-Netzwerkverbindungen, Voraussetzungen finden Sie Anweisungen zur Installation der Clientbibliotheken für TLS/SSL-Verbindungen.

Wenn ich aber in die entsprechenden Units schaue (REST.Client, REST.HTTPClient) so sehe ich dort nichts von Indy. Irritierend auch, dass man zur Konfiguration bestimmter SSL/TLS-Parameter sich der Winapi direkt bedienen muss(te, vor Tokyo) und eben nicht über Properties wie bei TIdSSLIOHandlerSocketOpenSSL . Das wäre dann ja nicht plattformunabhängig, doch compilerabhängige Uses sehe ich auch nirgends. Vielleicht könnte mich ja mal jemand erleuchten.

Grüße
Cody

[Daniel]

Nicht mehr.
Die REST-Komponenten in XE5 bis XE7 basierten auf den INDY-Komponenten, beinhalteten damals aber schon eine Abstraktionsschicht dazwischen, um die Komponenten tauschen zu können. Mittlerweile hängen die Net-Komponenten dazwischen, die dann auf den jeweiligen Plattformen nativ arbeiten.

[KodeZwerg]

Emba überlässt es Dir wie Du eine verschlüßelte Verbindung aufbaust.
Da Indy integeriert ist, bietet es sich dafür an.

Hier ein mini Beispiel (ohne Indy & ohne SSL) *klick mich*

[Daniel]

Nein, deine Antwort ist inhaltlich falsch.
Die REST-Komponenten basierten entweder auf den INDY-Komponenten (früher) oder auf den nativen Komponenten (jetzt). Entweder - oder. Eine Wahl hatte der Entwickler im Zusammenhang mit diesen Komponenten nie.

[Codehunter]

Also ist die Erklärung, dass das schlicht eine noch nicht korrigierte Altlast in der Emba-Doku in der deutschsprachigen Version ist. Jetzt wo ich drauf gestoßen wurde habe ich im englischen Bereich geschaut und siehe da, dort steht was anderes:

Zitat:

TRESTClient is built to hide any HTTP-related exceptions as long as the exception can be represented by a standard HTTP code. The client only throws 'hard' exceptions, connection failures, and so on. The framework operates on the newer TNetHTTPClient, which is based on system HTTP client sockets. This allows it to leverage the OS's ability to automatically resolve and deal with SSL/TLS/HTTPS.

[Codehunter]

Eine weitere Frage in dem Zusammenhang: Ich bin eigentlich ein Freund von den Indy-Komponenten, vor allem auch wegen der Flexibilität. Ist es zum jetzigen Zeitpunkt noch eine gute Idee, anstelle von TRestClient/TRESTRequest auf Indy und TJSONObject zu setzen?

[Neutral General]

Ehrlich gesagt sind wir bei uns von Indy jetzt komplett auf die nativen Komponenten umgestiegen.
Weniger Abhängigkeiten und ich persönlich finde sie besser und um einiges einfacher als die Indies.
Und für SSL braucht man dann auch nicht mehr die SSL-DLLs. Man übergibt eine url mit https statt http und es klappt.
Kein IOHandler, keine SSL-DLLs, etc.