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.
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 Antworten
@sh@softweaver
Wir freuen uns auf Ihr Feedback.
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!
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.
@sh@softweaver
Gerne nehmen wir Ihren Vorschlag auf.
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 🙂
@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.
nochnmals getestet
Ort Backnang funktioniert nur mit www1, Stuttgart nur mit www oder www2
Ansonsten kommt Fehler 302 "Moved temporaily"
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.
Interessant wird es, wenn der Hostname nicht genau bekannt ist.
z.B. bei dasOertliche.de ist der Host je nach Ort unter www1 ,www2, usw. zu finden.
Gute Idee! Wir nehmen das als Vorschlag auf.
Eine Methode für das Parsen von multipart/form-data Requests wäre noch eine schöne und praktische Erweiterung der Http-Struktur.
Hallo Klaus, danke für den Hinweis 🙂 Jetzt sollten sie aber funktionieren.
leider funktionieren die angegebenen Links zu den Artikeln nicht.