Programmierung

HTTP – Kommunikation im Web

Das HTTP-Protkoll stellt bei der Kommunikation im Web immer noch den Standard da. Sei es beim gemütlichen Browsen und Downloaden oder bei der Verwendung eines Web-Service.

Mit dem HTTP-Objekt von CONZEPT 16, haben Sie die Möglichkeit dieses Protokoll auch in Ihre Applikation zu implementieren, um beispielweise Daten von oder zu einem Web-Server zu übertragen oder einen eigenen Web-Service zu implementieren.

Kommunikation zwischen HTTP-Client und -Server

Mit dem HTTP-Objekt können Sie sowohl die client- als auch die server-seitige Implementierung realisieren. Dazu kann das Objekt in verschiedenen Modi geöffnet werden:

  • _HTTPSendRequest: Erstellen und Versenden einer Anfrage
  • _HTTPRecvRequest: Empfangen und Auswerten einer Anfrage
  • _HTTPSendResponse: Erstellen und Versenden einer Antwort
  • _HTTPRecvResponse: Empfangen und Auswerten einer Antwort

Neben dem Modus muss außerdem ein Deskriptor einer Socket-Verbindung übergeben werden, die zum Beispiel durch SckConnect() oder den SOA-Service geöffnet wurde.

Über Eigenschaften und Funktionen stellt das HTTP-Objekt den Zugriff auf die zu sendenden beziehungsweise zu emfpangenden Daten bereit.

In den Modi _HTTPSendRequest und _HTTPRecvRequest – zum Versenden und Empfangen einer Anfrage – wird beispielsweise die angefragte Ressource über die Eigenschafte spURI gesetzt beziehungsweise ermittelt. Und bei den Modi _HTTPSendResponse und _HTTPRecvResponse – zum Versenden und Empfangen einer Antwort – wird zum Beispiel der Status der HTTP-Kommunikation über die Eigenschaft spStatusCode gesetzt

beziehungsweise ermittelt.


Die Verwendung des HTTP-Objektes könnte dann wie folgend aussehen:

Client

Der Client ist diejenige Seite einer HTTP-Kommunikation, die Anfragen versendet und Antworten empfängt.

Beispiel
// Socket-Verbindung herstellen
tSck # SckConnect('blog.conzept16.de', 80, _SckOptDontLinger);

// HTTP-Objekt zum Versenden einer Anfrage öffnen
tHTTPReq # HTTPOpen(_HTTPSendRequest, tSck);
// Host setzen
tHTTPReq->spHostName # 'blog.conzept16.de';
// Ressource setzen
tHTTPReq->spURI # '/feed';
// Anfrage versenden und HTTP-Objekt der Anfrage schließen
tHTTPReq->HTTPClose(_HTTPCloseConnection);

// HTTP-Objekt zum Empfangen einer Antwort öffnen und
// HTTP-Header empfangen
tHTTPRsp # HTTPOpen(_HTTPRecvResponse, tSck);
// HTTP-Status ermitteln
tStatus # CnvIA(StrCut(tHTTPRsp->spStatusCode, 1, 3));
// Status = OK
if (tStatus = 200)
{
  // Speicherblock für HTTP-Body anlegen
  tMemBodyRsp # MemAllocate(_MemAutoSize);
  // HTTP-Body empfangen
  tHTTPRsp->HTTPGetData(tMemBodyRsp);
  // HTTP-Body verarbeiten
  // ...
  // Speicherblock freigeben
  tMemBodyRsp->MemFree();
}
// HTTP-Objekt der Antwort schließen
tHTTPRsp->HTTPClose(0);

// Socket-Verbindung beenden
tSck->SckClose();

Server

Der Server ist diejenige Seite einer HTTP-Kommunikation, die Anfragen empfängt und Antworten versendet.

Beispiel
// HTTP-Objekt für Anfrage öffnen
tHTTPReq # HTTPOpen(_HTTPRecvRequest, aSck);
// HTTP-Objekt für Antwort öffnen
tHTTPRsp # HTTPOpen(_HTTPSendResponse, aSck);
// Liste mit HTTP-Headern (Antwort) ermitteln
tCteListHeaderRsp # tHTTPRsp->spHTTPHeader;
// Speicherblock für HTTP-Body anlegen
tMemBodyRsp # MemAllocate(_MemAutoSize);
// Methode = GET
if (tHTTPReq->spMethod = 'GET')
{
  // Unterscheidung über angefragte Ressource
  switch (tHTTPReq->spURI)
  {
    case '/feed' :
    {
      // Content-Type setzen
      tCteListHeaderRsp->CteInsertItem('Content-Type', 0,
        'text/xml; charset=UTF-8');

      tMemBodyRecv->spCharset # _CharsetUTF8;
      tMemBodyRecv->MemWriteStr(_MemAppend,
        '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>',
        _CharsetC16_1252);
      tMemBodyRecv->MemWriteStr(_MemAppend, '<rss>');
      // ...
      tMemBodyRecv->MemWriteStr(_MemAppend, '</rss>');
    }
  }
}
// Antwort versenden und HTTP-Objekt schließen
tHTTPRsp->HTTPClose(_HTTPCloseConnection, tMemBodyRsp);
// Speicherblock freigeben
tMemBodyRsp->MemFree();
// HTTP-Objekt der Anfrage schließen
tHTTPReq->HTTPClose(0);

Artikel zum Thema HTTP:

  • CONZEPT 16 im Web
  • Webservices mit CONZEPT 16

Eine ausführliche Beschreibung und weitere Beispiele können Sie auch der CONZEPT 16-Dokumentation und der CodeLibrary entnehmen.

13 Kommentare

13 Kommentare “HTTP – Kommunikation im Web”

  1. Danke das ihr meinen Vorschlag umgesetzt habt. Leider bin ich erst seit diesem Monat wieder für die Fa. Softweaver tätig, hatte also seit meinem letzten Beitrag im Januar nichts mehr mit Conzept 16 zu tun und dadurch auch den Blog nicht mehr weiter verfolgt. Wie schon erwähnt hatte ich damals aber an einer eigenen Implementierung des Protokolls gearbeitet und dann auch fertig gestellt, wodurch das für uns jetzt erst einmal nicht mehr relevant ist. Aber für eure anderen Kunden ist das sicherlich sehr interessant und sobald ich die Zeit finde (Mittagspause oder Zuhause mit der Evaluierungslizenz), schaue ich mir die Neuerungen natürlich trotzdem mal an und gebe dann nochmal entsprechendes Feedback!

  2. Wir haben kürzlich einen SOAP-Client in CONZEPT 16-Quelltext realisiert, den wir in den kommenden Tagen auch hier im Blog vorstellen werden.

    Da Sie selbst wohl bereits Erfahrung mit SOAP in CONZEPT 16 gemacht haben, würden wir uns über Ihre Meinung dazu freuen.

  3. Der SOA-Server und das HTTP-Objekt sind an sich gute Ideen, was ich hier allerdings noch vermisse ist eine Implementierung des SOAP-Protokolls. Momentan schreibe ich eine eigene "Klasse", welche SOAP 1.1 implementiert. Damit können wir mit anderen Web-Services kommunizieren, bzw. mit dem SOA-Server "echte" Web-Services zur Verfügung stellen!

    Eine komplette SOAP-Unterstützung ist zwar ziemlich aufwändig, aber vielleicht nehmt ihr das ja trotzdem als Verbesserungsvorschlag von mir auf 🙂

  4. @Th.Eichele:
    Die Redirection Codes 3xx (z.B. 302 Moved Temporarliy, 301 Moved Permanently usw…) sind eigentlich keine Fehler, sondern geben an, dass die angeforderte Ressource unter einem anderen als dem angegeben URL zu finden sind. Im Header-Feld "Location" finden Sie den aktuell gültigen URL und können damit der Umleitung folgen.

  5. Subdomains wie "www1", "www2" usw. sind in der Regel redundanten Systemen zur Lastverteilung zugeordnet.

    Im Fall von dasoertliche.de scheinen alle Ressourcen auch unter jeder Subdomain – "www" und "wwwN" – verfügbar zu sein.

Kommentar abgeben