Suche API für einfachen HTTP-Zugriff.

[schoppenhauer_entfernt_]

Hallo.

Ich suche eine einfache API für den HTTP-Zugriff, die möglichst intuitiv ist und ein möglichst kurzes Tutorial beinhaltet, das mir sagt

• Wie ich einen Request zu einer IP oder einem Domainnamen mit Portnummer öffne
• Wie ich get-Variablen sende
• Wie ich post-Variablen sende
• Wie ich den Inhalt der angesteuerten Datei vom Server in einen String speichern kann

Ok. Das wäre der Idealfall... Allgemein würde mich halt eine HTTP-API interessieren...

 

[Murray]

Sowas?

 

[schoppenhauer_entfernt_]

Nein, ich glaube eher nicht. Denn: Nicht nur, dass da kein kurzes Tutorial existiert - es existiert anscheinend überhaupt kein Tutorial, nur ein sehr dämlicher "User Guide", der aber auch nichts nützt, wenn man sich nur begrenzt mit HTTP auskennt. Außerdem scheint das eher für Server als für Clients geschrieben zu sein.
Anscheinend scheint die Java-API aber (laut der Titlepage) bereits etwas für HTTP-Zugriffe zu enthalten.

Wirklich: ALLES was ich brauche, ist die Möglichkeit zum Senden von Requests mit GET- und POST-data, und die vom Server gesendete Datei als String. Und ich glaube für diese rudimentären Dinge ist die API die du vorgeschlagen hast etwas zu kompliziert. Und ihr fehlt es an einem richtigen Tutorial. Trotzdem danke natürlich.

 

[AlArenal]

Murrays API (httpclient) ist ziemlich easy. Wichtiger als die Funktionlität, die du nicht brauchst, sollte dir die sein, die du brauchst. DIese findest du eben in dieser Lib.

Zumal, wenn du selbst sagst von HTTP keine Ahnung zu haben, macht es wohl keinen Sinn wenn du selbst versuchst HTTP nachzucoden, oder? Der Lib selber isses auch völlig peng ob du sie client- oder serverseitig verwendest. HTTP ist HTTP. Musst du dir überlegen, ob es Sinn macht etwas nachcoden zu wollen, von dem man nichts weiß. Du wirst nicht umhin kommen dich ein klein wenig mit der FUnktionsweise von HTTP zu beschäftigen.

 

[schoppenhauer_entfernt_]

Murrays API (httpclient) ist ziemlich easy. Wichtiger als die Funktionlität, die du nicht brauchst, sollte dir die sein, die du brauchst. DIese findest du eben in dieser Lib.

Zumal, wenn du selbst sagst von HTTP keine Ahnung zu haben, macht es wohl keinen Sinn wenn du selbst versuchst HTTP nachzucoden, oder? Der Lib selber isses auch völlig peng ob du sie client- oder serverseitig verwendest. HTTP ist HTTP. Musst du dir überlegen, ob es Sinn macht etwas nachcoden zu wollen, von dem man nichts weiß. Du wirst nicht umhin kommen dich ein klein wenig mit der FUnktionsweise von HTTP zu beschäftigen.

Guderle... Ich hab die RFC teilweise gelesen - daher weiß ich, dass man sich nicht immer beim Server authentifizieren muss, etc., was in dem tollen User-Guide zwar fabelhaft beschrieben ist, mich aber wenig interessiert. Wenn ich was größeres machen wollen würde, würd ich das direkt selber mit Sockets machen. Aber das ist mir bei HTTP dann für das bissel was ich damit vorhabe doch aweng zu dumm.
Wie man Get- und Postdata verschickt steht leider nirgends.
Anstatt mir hier dämliche Ratschläge der Form "Lass es lieber, du bist eh zu blöd" zu geben, hättest du mir ja produktiver Weise einen Link zu dem anscheinend doch existierenden nur sehr gut versteckten Tutorial geben können. Da hätt ich wenigstens was davon. Leider steht dadrinnen auch nicht, wie man Postdata schickt.

Achja... Es macht einen gewaltigen Unterschied ob man einen Server oder einen Client programmiert - andere Fehler treten auf, Befehle sind anders, und und und ... - und es ist keineswegs klar, dass man eine API für beides verwenden kann. Dies trifft bereits auf so Sachen wie IRC zu, wo die Unterschiede zwischen Server und Client noch wesentlich kleiner sind als bei HTTP.

 

[Roar]

- hier wird das gemacht, was du machen willst: http://jakarta.apache.org/commons/httpclient/tutorial.html
- das was du machen willst geht auch mit java.net.URL und HttpURLConnection

 

[AlArenal]

Guderle... Ich hab die RFC teilweise gelesen - daher weiß ich, dass man sich nicht immer beim Server authentifizieren muss, etc., was in dem tollen User-Guide zwar fabelhaft beschrieben ist, mich aber wenig interessiert.

Nichts und niemand hält dich davon ab den Teil der API links liegen zu lassen, den du nicht brauchst. Mich interessieren auch nicht die Unmengen an Klassen der JFC, die ich nicht direkt nutze...

Wenn ich was größeres machen wollen würde, würd ich das direkt selber mit Sockets machen. Aber das ist mir bei HTTP dann für das bissel was ich damit vorhabe doch aweng zu dumm.

Komisch. Es gibt ne ganze Menge recht großer Projekte unter dem Apache-Deckmantel und die bneutzen alle HttpClient, wenn sie mit Http arbeiten. Die Lib ist gewissermaßen ein Abfallprodukt.

Wie man Get- und Postdata verschickt steht leider nirgends.
Anstatt mir hier dämliche Ratschläge der Form "Lass es lieber, du bist eh zu blöd" zu geben, hättest du mir ja produktiver Weise einen Link zu dem anscheinend doch existierenden nur sehr gut versteckten Tutorial geben können. Da hätt ich wenigstens was davon. Leider steht dadrinnen auch nicht, wie man Postdata schickt.

Anstatt patzig zu werden, hättest du besser mal aufmerksamer lesen sollen. Im Tutorial ist doch groß und breit erklärt, wie man grundlegend mit der Lib arbeitet, dargestellt anhand eines kleinen Beispiels mit GET. Aus folgendem Ausschnitt lässt sich ohne tiefere Kenntnis der Lib erkennen, dass es eine Klasse GetMethod gibt und diese entweder ein Interface HttpMethod implementiert, oder von einer gleichnamigen Klasse abgeleitet ist. Das legt den Schluss nahe, dass es evtl. auch eine Klasse PostMethod geben könnte.

We will be using the Get method which is a simple method that simply takes a URL and gets the document the URL points to.

HttpMethod method = new GetMethod("http://www.apache.org/");

Achja... Es macht einen gewaltigen Unterschied ob man einen Server oder einen Client programmiert - andere Fehler treten auf, Befehle sind anders, und und und ... - und es ist keineswegs klar, dass man eine API für beides verwenden kann. Dies trifft bereits auf so Sachen wie IRC zu, wo die Unterschiede zwischen Server und Client noch wesentlich kleiner sind als bei HTTP.

Obiges Bla werte ich als weiteres Indiz für deinen Unwillen zu LESEN. Steht alles sehr umfassend und übersichtlich auf der Projekt-Seite, zu der Murray die den Link ja genannt hatte.

Eigeninitiative ist ausdrücklich erwünscht.

 

[AlArenal]

Man beachte auch den dortigen Link zum Projekt-Wiki und dort wiederum die Seite mit dem Titel "For Absolute Beginners": http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners

Kann doch nicht so schwer sein, einen Webbrowser zu bedienen...

 

[schoppenhauer_entfernt_]

Wie man unschwer erkennen kann handelt es sich bei dieser Methode um eine GET-Method. Ich brauche eine POST-Method. Diese gibt es auch.

Wie dem auch sei. Sorry, dass ich nicht so freundlich wie sonst bin, aber mich nervt es einfach, wenn leute vollkommen unproduktive Posts schreiben, die einfach zur Lösung eines Problems NICHT beitragen... Dass ich selber weitersuche, auch wenn ich schreibe, dass ich nichts finde, dürfte ja klar sein. Ich brauche niemanden, der mir das sagt.

 

[AlArenal]

Alles was du brauchst findest du hinter Murrays Link. MICH nervt es, wenn man zum aufmerksamen Weitersuchen und Lesen noch zu faul ist und stattdessen lieber andere nervt, einem doch eine auf einen selbst zugeschneiderte Maßarbeit als Lösung zu liefern.

Hilf dir selbst, dann hilft dir Gott.

*5euroinsphrasenschweinwerf*

 

[Illuvatar]

- das was du machen willst geht auch mit java.net.URL und HttpURLConnection

Halte ich, ehrlich gesagt, auch für sinnvoller.

Ansonsten noch --> Link <--, da geht es um URLConnection und um ein Post per Jakarta HttpClient.

 

[AlArenal]

- das was du machen willst geht auch mit java.net.URL und HttpURLConnection

Halte ich, ehrlich gesagt, auch für sinnvoller.

Ansonsten noch --> Link <--, da geht es um URLConnection und um ein Post per Jakarta HttpClient.

"sinnvoller" ist immer relativ, da wir nicht die genauen Rahmenbedingungen kennen. Spätestens wenn dur irgendwo nen Proxy dazwischen hast, oder serverseitig ein IIS mit Authentifikation arbeitet, hast du nämlich mit Javas Low-Level Bordmitteln ziemlich verloren. Wenn du dann später vielleicht mal auf HTTPS umstellen willst... usw. usf.

 

[karstenkurt]

Hallo,

bin neu hier und hätte da mal eine kleine Frage zum httpclient.
Kommunikation klappt, allerdings bekomme ich von Server eine HTML-Seite zurück, in welcher

<meta http-equiv="refresh" content="7; URL=login_ok.php?
status=kostenlos&adomain=antispam24.de&usern=xxx">

steht. Wie bekomme ich den Redirect denn gefangen? Hab schon versucht die Seite nach 7 sec. erneut abzufragen, oder 7 sek. zu warten und den getResponseBodyAsStream() erst dann abzuziehen, klappt aber alles nicht. In der oben angegebenen Doku konnte ich nix finden.

Vielen Dank für die Hilfe
KK

 

[AlArenal]

Das Problem ist, dass es sich nicht um einen HTTP-Redirect handelt, sondern dieser im Content steht und mit Content hat HttpClient nichts am Hut, weil der ja mit dem Protokoll (also HTTP) selber auch nichts zu tun hat.

D.h. du bist selbst dafür verantwortlich den Content zu parsen und ggf. erneut ein GET durchzuführen. Wie die HttpClient-Jungs sagen: "It's not a browser".

 

[karstenkurt]

Hi,

danke für die Antwort. Das ist ja gerade mein Problem. Da kommt dann immer (egal wie lange ich warte) der Text "Bitte warten...." :shock:

 

[AlArenal]

Beschwer dich bei dem, der die Website entwickelt hat.

 

[karstenkurt]

Nee Du. Ich nehm nen anderes Spam-Postfach

Danke

 

[Lim_Dul]

Hi,

danke für die Antwort. Das ist ja gerade mein Problem. Da kommt dann immer (egal wie lange ich warte) der Text "Bitte warten...." :shock:

Du darfst ja auch nicht gleiche Seite abfragen. Sondern musst die, in dem Redirect angegebene URL abfragen.