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

Delphi-Quellcode:

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.

[Codehunter]

Zitat:

Zitat von Neutral General (Beitrag 1417034)

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.

Ja denkste, das war genau der Grund warum ich so viel suchen musste. Auf Windows 10 liefs wunderbar mit TRESTClient, auf Windows 7 nicht und keiner wusste warum. Bis ich dann mit dem Wireshark aufdröseln musste was eigentlich schief geht. Unter Win 7 sind per Default weder TLS 1.1 noch TLS 1.2 verfügbar und auch das Aushandeln der Stromchiffren ging vor den Baum. Und das rauszufinden ist bei verschlüsselten Verbindungen mit Wireshark ein einziger Krampf :evil: Ursache war zwar serverseitig, aber man hat ja trotzdem die Arbeit. Und das nur, weil mit der OS-nativen Inet-Kommunikation auch mehr Unwägbarkeiten ins Spiel kommen. Und, was man ja bedenken sollte: Sobald ein Windows aus dem Support fällt, werden dort auch keine neuen Stromchiffren oder TLS-Versionen mehr kommen. Bei den OpenSSL-DLLs dagegen schon (zumindest länger)

Vielleicht ist Indy mit mehr Einarbeitung verbunden, aber Debuggen geht IMHO einfacher. Wobei ich ergänzend sagen muss, dass ich schon ein funktionierendes REST-Framework mit Indy habe. Es ist also keine Frage des Implementierungsaufwandes sondern mehr eine Grundsatzfrage.

[Sherlock]

Ein aus dem Support gefallenes Windows sollte man aus reinem Selbsterhaltungstrieb nicht supporten.

Sherlock

[Codehunter]

Zitat:

Zitat von Sherlock (Beitrag 1417036)

Ein aus dem Support gefallenes Windows sollte man aus reinem Selbsterhaltungstrieb nicht supporten.

Das kann man nicht pauschalisieren. Jede Branche hat eine ganz eigene Clientel und manchmal sagt der Selbsterhaltungstrieb, auch ältere Windows noch zu unterstützen (supporten tun wir die nicht)

[Sherlock]

Klar es ist eine Kosten/Nutzungsrechnung. Wenn die positiv ausgeht, ist alles in Butter. Aber je älter ein Windows ist, desto mehr tendiert besagtes Ergebnis ins negative.

Sherlock

[KodeZwerg]

Zitat:

Zitat von Sherlock (Beitrag 1417036)

Ein aus dem Support gefallenes Windows sollte man aus reinem Selbsterhaltungstrieb nicht supporten.

Sherlock

Der Support für Windows 7 endet am 14. Januar 2020.

[Sherlock]

Zitat:

Zitat von KodeZwerg (Beitrag 1417041)

Zitat:

Zitat von Sherlock (Beitrag 1417036)

Ein aus dem Support gefallenes Windows sollte man aus reinem Selbsterhaltungstrieb nicht supporten.

Sherlock

Der Support für Windows 7 endet am 14. Januar 2020.

Dann gibt es auch eine zeitgemäße Transportverschlüsselung? Dann gibt es freilich erst nach dem 14.01.2020 ein diskussionswürdiges Thema :D

Danke für den Hinweis.

Sherlock

[Codehunter]

Wobei der Windows-Support hier nicht das Thema ist sondern die Frage ob Indy strategisch eine gute Wahl ist oder eben nicht. Ich halte es jedenfalls für sinnvoll weil OS-unabhängig.

Dass gerade die Emba-Implementierung auf dem derzeit noch aktuellen Windows 7 per Default weder TLS 1.1 noch 1.2 unterstützt, auf Win 10 dagegen schon, obwohl beide auch auf Win 7 verfügbar wären und nur aktiviert werden bräuchten, das sagt mir dass die Implementierung Schwächen hat. Dass der Server aber nur noch zwei RSA-Stromchiffren akzeptieren wollte war dann doch etwas "übersichert" ;-)

[Schokohase]

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.

[Codehunter]

Zitat:

Zitat von Schokohase (Beitrag 1417044)

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.