REST Webservice

[gast2]

Hallo,

kann mir einer REST etwas näher erklären? Ich beschäftige mich gerade generell mit Webservices, aber bei REST steig ich nicht durch. Die Architektur an sich ist schon klar, aber z.b. die xml-Docs die da hin und hergeschickt werden...muß nicht irgendwo (in einer config oder so) definiert sein wie die aufgebaut sind?

Dann, woran wird bekannt gemacht das es sich um einen Webservice handelt? Im falle von Axis/SOAP gibt es ja die *.wsdd die definiert wo der Service liegt und wie er angesprochen werden darf.

Genauer gesagt wo ist der Unterschied zw. einem normaler Servletaufruf .../warenkorb und den RESTwebservice-Aufruf Warenkorb (um mal bei dem viel genannten Warenkorbbsp. zu bleiben)???

Wenn ich vom Service einen Antwort-XML bekomme...muß ich die auf meiner HMTL/JSP(whatever) dann per Hand auseinander auseinanderpflücken und auswerten oder wie soll das Ganze aussehen?

Irgendwie finde ich da kein gutes Tutorial bzw. meist nur Artikel die die Bedeutung von REST erläutern.

Kann mir da wer Licht ins Dunkle bringen?

Danke,
gast2

 

[JUnkie]

Du denkst zu kompliziert: Das schöne an REST ist ja, dass es so einfach ist. REST muss ja nichtmal XML verwenden. Es gibt daher auch keine DTDs oder so. SOAP ist kompliziert, die einzige Gemeinsamkeit mit REST ist eigentlich, dass es wie REST auf HTTP aufsetzt.

 

[gast2]

Du denkst zu kompliziert:

das denke ich mittlerweile auch. Aber dennoch kannst du mir sagen wie die warenkorb-xml die der Client zurückbekommt (<warenkorb><item>1</item><item>2</item></warenkorb>)...oder besser deren Inhalte nun in meine tolle HTML zur Darstellung kommen? Das raff ich nicht so wirklich...

Ich mein wenn das ganze Web auf Rest basiert dann ist doch quasi jede Antwort auf ne http-Anfrage ein Webservice oder wie?

gruß,
gast2

 

[JUnkie]

wenn das ganze Web auf Rest basiert dann ist doch quasi jede Antwort auf ne http-Anfrage ein Webservice oder wie?

Ja, so könnte man es sehen.

Das XML, was Du zurück bekommst, kannst Du verwerten, wie Du willst. Natürlich musst Du daraus HTML machen, um es im Web darzustellen. Als Standard für diesen Vorgang gibt es XSLT. Du kannst auch selbst einen Parser schreiben, wenn Du Lust hast.

 

[gast2]

wie sieht das denn bei Axis/SOAP aus da wird ja über xml kommuniziert. wie wird das Ergebnis dann umgewandelt? muß man sich da auch selbst drum kümmern?

gruß,
gast2

 

[JUnkie]

Bei SOAP geht es ja besonders um RPCs. Nicht jede Antwort möchte man darstellen, nicht jede Antwort eignet sich überhaupt dazu bzw. ist dafür gedacht. Ich denke, ich weiß schon, was Du willst. Aber ein bisschen muss man schon dafür tun. Axis kenne ich nicht genau. Aber ich kann Dir sagen, dass es verschiedene Java-APIs zum Parsen von XML gibt. Damit hast Du es schon sehr einfach.

 

[gast2]

also ich will eigentlich gar nichts
Ich beschäftige mich nur mit dem Thema und den möglichen Techniken. Die Axis-Geschichte hab ich soweit gut verstanden (denke ich), nur bei REST ist irgendwie immer alles so schön schwammig geschrieben.

Ich hab mir mal Axis installiert und einige Testanwendungen, die dabei waren ausgefürt. Mich hat halt gewundert das bei den mit glieferten Testanwendungen auch immer nur xml dargestellt wurde ala:

<soapenv:Envelope>
	<soapenv:Body>
	<simpleEchoResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<simpleEchoReturn xsi:type="xsd:string">3</simpleEchoReturn>
</simpleEchoResponse>
</soapenv:Body>
</soapenv:Envelope>

allerdings bekomme ich da vom Browser immer auch die Meldung:

Mit dieser XML-Datei sind anscheinend keine Style-Informationen verknüpft. Nachfolgend wird die Baum-Ansicht des Dokuments angezeigt.

Ist damit sowas wie das von dir angesprochene XSLT gemeint? Oder etwas ähnliches das quasi xml in html "mappt"?
Dann wär ich zufrieden

Kennst du dich zufällig noch mit Uddi aus? :wink:

gruß,
gast2

 

[JUnkie]

Der Code ist eine einfache SOAP-Antwort. Im Body ist kein XML zu sehen, das man konvertieren und darstellen könnte.

XSLT wird normalerweise benutzt, um auf der Serverseite aus XML irgendwas abderes zu machen, häufig halt HTML. Das was Dein Browser (also Dein Client) da ausgibt, heißt nur, dass er verzweifelt versucht, dass beste aus einem Dokument zu machen, das überhaupt nicht für ihn geschaffen wurde. Diese SOAP-Antwort wird auf einem Server verwertet.

UDDI ist keine große Sache. Google mal.

 

[gast2]

danke erstmal für deinen ganzen Antworten

Also eigentlich ist der Soap-Code von oben ja die Response die an den Clienten soll...wenn das nicht für den Browser gedacht ist, an welcher Stelle muß das dann Browserkonform gemacht werden? Alle mitgelieferten Beispiele geben mir sowas zurück wenn ich den Service mit den entsprechend zugelassenen Methoden und Parametern über den Browser aufrufe...

Vielleicht hab ich einfach nur ein Brett vor dem Kopf aber ich raff diese Schnittstelle SOAP/Browser nicht...

Ich hab leider bisher noch kein "vollständiges" Bsp im Web gefunden...die Prinzipien sind soweit klar nur die "Antwortverwertung" nicht so recht...

Ich dachte schon mir fehlen irgendwelche Bibiloteken...es sind teilweise komplexe BSP mit wsdds und auch einfache jws...



Was Uddi betrifft, da hab ich mich schon belesen und bin am installieren/ausprobieren. Bekomme nur nen komischen Fehler bei der Ausführung...der sich aber als SaxParser-Fehler herausstellte (SOAPException: faultCode=SOAP-ENV:Client - das schließende "</HR>" Tag fehlt, aber ich hab keinen blassen schimmer auf welches Dokument er sich da bezieht). FLiegt immer wenn ich mit dem TModel was mache (Inquery). Na mal schaun...


gruß,
gast2

 

[JUnkie]

Okay, hatte mich missverständlich ausgedrückt:

Mit "auf der Serverseite" meinte ich eine Webanwendung. Damit wollte ich ausdrücken, dass Dein Browser mit SOAP nichts zu tun hat, außer, dass er Dir Antworten darstellen kann.

Ein Server kann über SOAP oder REST Deinem Server XML senden, das Du dann auf einem Server mit XSLT meinetwegen in HTML umwandelst und dann an einen Browser schickst. Das ist dann eine Webanwendung, die einen fremden Webservice nutzt, um Clients darauf basierende Webseiten zu bieten.

 

[JUnkie]

Darf ich fragen, warum Du Dich mit dem Thema beschäftigst? Bist Du Softwareentwickler oder Student?

 

[AlArenal]

Bei REST ist alles "schwammig" weil REST nicht definiert wie der Content auszusehen hat. Ob Text, binäre Daten, XML - egal!

SOAP kommt gleich mit recht viel Komplexizität daher, die man eben nicht immer braucht. Kein Mensch mag WSDL..

Übrigens wird man in der nächsten großen Version des Ruby on Rails Frameworks den AJAX-Kram von SOAP auf REST als Default-Mechanismus umstellen. Die ganzen Features, die man vielleicht im Enterprise-Bereich noch unterbringen kann und die SOAP so fett machen, brauchts nämlich nicht.

Es gibt sie immer wieder, die gute alte 80/20-Regel...