SOAP: MYSQL-DB Zugriff

[sephraina]

Hmmm, zuerst mal Danke an Alle für die Antworten.

Dann doch eher REST...
Habe ich mir schon vorher überlegt, aber die Tutorials (vor allem von embarcadero) gehen so ziemlich schnell auf DataSnap über.
Leider wird aber DataSnap in meiner Delphiversion nicht unterstütz, was heissen würde, ich müsste alles neu schreiben, oder gibts da Vorarbeiten (Codeschnipselbeispiele für die ganzen GET, POST usw.), die mir einen Anhaltspunkt/Starthilfe geben könnten?

Gruss und Danke

[mkinzler]

http://www.delphipraxis.net/184570-e...erstellen.html

[mjustin]

Zitat von sephraina:

(Codeschnipselbeispiele für die ganzen GET, POST usw.), die mir einen Anhaltspunkt/Starthilfe geben könnten?

Hier ist ein POST Beispiel für JSON an einen Webserver. Es erfordert allerdings Indy 10.6.2, und da es HTTPS verwendet auch die SSL Bibliotheken im gleichen Verzeichnis wie die Anwendung. Man kann aber das https://httpbin.org/post auch durch http://httpbin.org/post ersetzen, dann geht es ohne SSL Bibliotheken.

Delphi-Quellcode:

program JSONPostExample;
 
{$APPTYPE CONSOLE}
 
uses
  IdHTTP, IdGlobal, SysUtils, Classes;
 
var
  HTTP: TIdHTTP;
  RequestBody: TStream;
  ResponseBody: string;
begin
  HTTP := TIdHTTP.Create;
  try
    try
      RequestBody := TStringStream.Create('{"日本語":42}',
        TEncoding.UTF8);
      try
        HTTP.Request.Accept := 'application/json';
        HTTP.Request.ContentType := 'application/json';
        ResponseBody := HTTP.Post('https://httpbin.org/post',
          RequestBody);
        WriteLn(ResponseBody);
        WriteLn(HTTP.ResponseText);
      finally
        RequestBody.Free;
      end;
    except
      on E: EIdHTTPProtocolException do
      begin
        WriteLn(E.Message);
        WriteLn(E.ErrorMessage);
      end;
      on E: Exception do
      begin
        WriteLn(E.Message);
      end;
    end;
  finally
    HTTP.Free;
  end;
  ReadLn;
  ReportMemoryLeaksOnShutdown := True;
end.

Serverseitig hat man dann natürlich auch noch ein wenig zu tun, im Beispiel wird httpbin.org verwendet, an dem man einfache Tests für GET, POST, PUT, etc. vom Client aus durchführen kann.

[Mavarik]

Zitat von sephraina:

Hmmm, zuerst mal Danke an Alle für die Antworten.

Dann doch eher REST...

Ich nehme auch lieber SOAP...

Viel einfacher und deutlich handlicher, weil "einfache Proceduren" aufrufen...

Größere Daten einfach vorher packen!

Klar hat man mehr Overhead... Würde auch nur Dif's schicken...

Mavarik

[Darlo]

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

[vagtler]

Zitat von Darlo:

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

Krass. Damit hättest Du unsere Akzeptanzkriterien beim Antwortverhalten von Schnittstellen mindestens um Faktor 10 gerissen...

[Darlo]

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

[Bernhard Geyer]

Zitat von Darlo:

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

AH. Also doch eher Businessobjekte die du per SOAP komplett übertragen willst statt nur (wie bisher diskutiert) "dumme" Tabelleninhalte.
Dafür ist natürlich SOAP ganz gut geeignet wenn man das so zusammenfast das alles über eine Abfrage übertragen angefragt und wieder zurück übertragen wird.
Dann hat man "nur" den großen Overheader der XML-Übertragung gegenüber eine JSON-Lösung.

[Sir Rufo]

Zitat von Bernhard Geyer:

Zitat von Darlo:

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

AH. Also doch eher Businessobjekte die du per SOAP komplett übertragen willst statt nur (wie bisher diskutiert) "dumme" Tabelleninhalte.
Dafür ist natürlich SOAP ganz gut geeignet wenn man das so zusammenfast das alles über eine Abfrage übertragen angefragt und wieder zurück übertragen wird.
Dann hat man "nur" den großen Overheader der XML-Übertragung gegenüber eine JSON-Lösung.

• Diskutiert haben wir bisher über die Anforderung vom TE.
• Darlo nimmt SOAP für seine komplexen Rechnungen, was für ihn ok ist.
• Darlo <> TE

Mit REST kann man auch komplexe Business-Objekte übertragen, am Server auswerten, durchnudeln, ... und ist nicht auf JSON beschränkt. Eigentlich auf gar nichts beschränkt, der REST-Server muss es nur verstehen, was ich dem schicke

[Mavarik]

Zitat von vagtler:

Zitat von Darlo:

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

Krass. Damit hättest Du unsere Akzeptanzkriterien beim Antwortverhalten von Schnittstellen mindestens um Faktor 10 gerissen...

Viele Leute haben eine Ping der höher liegt...

Aber 4 gleichzeitig? Von selben Gerät? Wie viele Anfragen der Server bewerkstelligt, hängt doch nur von der Netzwerkanbindung ab und ggf. von der Prozessorleistung...
Und da müssen es echt viele Anfragen sein um zu sagen... Hätten wir nicht den XML Overhead würde es noch gehen...

Mavarik