Basiert TRESTClient WIRKLICH auf Indy?

[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.