TIdHTTP zu THTTPClient umschreiben, THttpClient ableiten und Get() überschreiben

[Uwe Raabe]

Zitat von DieDolly:

Mir fällt gerade aber auch auf, dass das hier gar nicht funktioniert und mit einem abstrakten Fehler beendet wird. Nur wieso?

THTTPClient ist nur die Basisklasse. Die eigentlich verwendete Klasse wird in THTTPClient.Create je nach verwendeter Plattform bestimmt. Wichtig: THTTPClient.Create ist kein constructor!

Delphi-Quellcode:

class function THTTPClient.Create: THTTPClient;
begin
  Result := THTTPClient(TURLSchemes.GetURLClientInstance('HTTP')); // do not translate
end;

Eventuell wäre ein zielführender Ansatz, von TRESTHTTP abzuleiten (der hat schon das FHTTPResponse Feld) und dort ein weiteres GET-overload anzufügen, das deinen Wünschen entspricht.

[DieDolly]

(ich darf verkünden, der Code da unten funktioniert. Alles ist eingebaut und bleibt jetzt so. Vielen Dank an alle)

Könntest du mir dabei helfen?

Mein Ziel mit der eigenen Klasse:
so wenig Zeilen wie möglich, wenn ich irgendwo was mit HTTP machen möchte - so habe ich das aktuell ja auch schon mit TIdHTTP.
THTTPClient würde, wenn ich den abstrakten Fehler nicht hätte, sofort funktionieren so wie ich es jetzt habe.

Das überschrieben Get brauche ich nur, damit ich im Get selber dann noch HttpResponse: IHttpResponse; setzen kann. Damit habe ich dann pro HTTP-Aufruf irgendwo im Programm wieder ein paar Zeilen weniger und kann direkt auf ein von mir im der eigenen HttpClient-Klasse deklarierten HttpResponse zugreifen, ohne extra über IHttpResponse gehen zu müssen.

Ist TRestHTTP besser? Das Respnse-Feld ist schon drin, das wäre natürlich gut. Aber ich weiß nicht wie man das nutzen soll. Ich sehe hier irgendwas mit Streams und get ist eine Prozedur statt Funktion. Das wäre ja wieder mehr Aufwand als das was ich jetzt schon habe.

Kann ich nicht doch irgendwie THTTPClient nutzen?

Ich glaube ich bin zu dumm für Streams und sowas. Hier meine zusammengepfuschte Lösung. Wenn ich alles so lasse wie ich es jetzt unten stehen habe, habe ich pro Aufruf nicht mehr Code als ich im Projekt wo ich das brauche eh schon habe. Beim Aufruf wäre auch bestimmt ein 1-Zeiler möglich, aber an manchen Stellen verwende ich die HTTP-Instanz noch weiter. Eigentlich brauche ich noch eine overload Post() Methode. Meinem alten Code übergebe ich einfach TStrings. TRestHTTP will einen Stream, deswegen lasse ich das sein. Streams sind ein Geheimnis für mich.

Delphi-Quellcode:

type
 THTTPCustom = class(TRESTHTTP)
 public
  ResponseContent: TStringStream;

  procedure Get(const AURL: string); overload;

  constructor Create;
  destructor Destroy; override;
 end;

constructor THTTPCustom.Create;
begin
 inherited Create;

 ResponseContent := TStringStream.Create;
end;

destructor THTTPCustom.Destroy;
begin
 inherited Destroy;

 ResponseContent.Free;
end;

procedure THTTPCustom.Get(const AURL: string);
begin
  ResponseContent.Clear; // wenn ich mit einer THTTPCustom-Instanz mehrfach Get() ausführe, sind die Ergebnisse sonst falsch
  ResponseContent.Seek(0, soBeginning);
  inherited Get(AURL, ResponseContent);
end;

procedure TForm3.Button2Click(Sender: TObject);
var
 HttpClient: THTTPCustom;
begin
 HttpClient := THTTPCustom.Create;
 try
  HttpClient.Get('domain');
  showmessage(HttpClient.Response.ContentAsString() + ' - ' + HttpClient.ResponseCode.ToString);
 finally
  HttpClient.Free;
 end;
end;

[Uwe Raabe]

[QUOTE=DieDolly;1504481]
THTTPClient würde, wenn ich den abstrakten Fehler nicht hätte, sofort funktionieren so wie ich es jetzt habe./QUOTE]

Die Architektur rund um THTTPClient sieht vor, dass Ableitungen für unterschiedliche Plattformen erstellt werden. Damit fallen Ableitungen für funktionalen Erweiterungen, so wie du sie geplant hattest, erst einmal aus. Das muss dann in Wrapper-Klassen realisiert werden, wie es ja in TRESTHTTP und, in einem höheren Level, in TRESTClient realisiert sind. Ich kann aber verstehen, wenn diese Klassen für deine Zwecke etwas viel Overhead haben. Trotzdem schön, dass du es zum Laufen gebracht hast.

[DieDolly]

Das ursprüngliche Problem liegt sicher nicht an TIdHTTP. Aber bevor ich mich mit meinem provider rumärgere, doch lieber weg damit und rein mit REST.
Die Programmanpassungen habens sich in Grenzen gehalten und alles war am Ende in 30 Minuten erledigt.

Außerdem bin ich mit REST jetzt die OpenSSL-Dateien los.

Noch zur Erklärung wofür ich als Response Text und Zahl brauche:
Text, weil meine API bestimmte Zeichenketten zurückgibt, die ich im Programmauswerte.
Zahl, weil ich einen Cooldown in der API habe. Häufen sich die API-Aufrufe für eine bestimmte IP in einem bestimmten Zeitfenster, gehen Anfragen von dieser IP nicht mehr durch und bekommen ein 403 zurück.