frage zu webservice

Hi,

ich würde gerne meine Kentnisse in der Webentwicklungerweitern,
und einen Webservice programmieren,
jetzt stellt sich natürlich die Frage was ich damit machen will:
1.Sachen aus der DB auslesen bzw reinschreiben
und 2. Dateien wie Bilder + Dokumente von einem Nutzer Account abrufen.

restfull oder soap was ist eurer Meinung besser geeignet?
Bzw. was benutzen Twitter und Facebook?

gruß

Mach doch beides

Ja ich versteh irgendwie nicht den Unterschied, obwohl ich schon einiges gelesen habe
irgendwie muss es ja vor oder nachteile geben oda?

kann mir jemand vllt ein gutes buch dazu empfehlen, also soap oder restfull ?

Hallo,

die Vor- und Nachteile sind schwer zu benennen oder abzuwägen. Ein ReST-Verfechter kann dir imho ebensoviele Gründe für ReST nennen, wie ein RMI-Verfechter für SOAP. Ich würde sagen, dass es zu einem großen Teil subjektiv ist.

Meine (hoffentlich halbwegs objektive) Meinung dazu ist, dass SOAP (wenn die WSDL steht) fast so intuitiv zu benutzen ist, als würde man lokale Objekte befummeln. Dafür ist es ein nicht unerheblicher Aufwand, die XML Schemas und die WSDL festzulegen.

ReST ist leichter zu ergänzen und zu erweitern und wegen der Zustandslosigkeit auch sofort in einer Load-Balancing-Umgebung einsetzbar. Im Vergleich zu anderen typischen Umgebungen muss man bei den Objekten und Methoden etwas umdenken. Da es nur 4 (+1) Methoden gibt (CRUD-Methodensatz + Options), müssen Objekte teilweise sehr stark zergliedert werden.

Ich finde, die Ansätze sind beide extrem cool, aber so unterschiedlich, dass man tatsächlich Äpfel und Birnen vergleichen müsste.

Gruß,

Amica

ok danke gut zu wissen
kennt jemand um so etwas zu lernen gute bücher oder wie würdet ihr das ganze angehen?

Also ich hab mir damals Architectural Styles and the Design of Network-based Software Architectures durchgelesen. Das ist die Dissertation vom "Erfinder" des ReST. Alles andere war learning by doing. Wenn man das Konzept einmal verinnerlicht hat (und das ist nicht so viel) ist der Rest reine Fleißarbeit und gute Kenntnis des HTTP-Protokolls.

Bei SOAP hab ich nur Grundkenntnisse. Deswegen kann ich da grad keine Referenzen nennen.

Wenn du aber auf der Suche nach Büchern bist, gibt es da so einen großen, bekannten Anbieter, wo man aus den Bewertungen und den Rezensionen einen guten Eindruck bekommt, ob ein Buch generell was taugt und für wen es besonders geeignet ist (bezogen auf das vorausgesetzte Vorwissen).

Zitat von AmicaNoctis

Bei SOAP hab ich nur Grundkenntnisse. Deswegen kann ich da grad keine Referenzen nennen.

... und sollte ohnehin verboten werden. Ein Protokoll mit mehr Overhead als Payload ist einfach nur beschissen, beschissen, beschissen! Ich kanns gar nicht oft genug sagen, beschissen! Hat mich das schon Nerven und Haare gekostet!

rest und http
kannst du dir hier mal bitte das inhaltsverzeichnis ansehen und gucken was von dem buch zu halten ist?

gruß

Zitat von unset

... und sollte ohnehin verboten werden. Ein Protokoll mit mehr Overhead als Payload ist einfach nur beschissen, beschissen, beschissen! Ich kanns gar nicht oft genug sagen, beschissen! Hat mich das schon Nerven und Haare gekostet!

unset ist also ganz offensichtlich kein Anhänger der Seife

Wenn du mal ganz von den "Besonderheiten" der beiden Techniken abstrahierst, handelt es sich um Netzwerkprotokolle. Und wenn du transparent für die Gegenseite beides unterstützt, ist das meiner Meinung nach ein einfach zu erreichender Mehrwert. Je nach Umfeld der Gegenseite kann der eine oder andere Ansatz attraktiver sein. SOAP ist beispielsweise in .Net sehr schnell eingebunden, während du in JavaScript sicherlich mit einer Restful/JSON-Schnittstelle gut fährst.

Zitat von Jonas22

kannst du dir hier mal bitte das inhaltsverzeichnis ansehen

Das Inhaltsverzeichis ist jetzt nicht so vielsagend, die Rezensionen schon eher, aber die kannst du sicher selbst lesen. Die Bewertung ist imho auch recht eindeutig.

SOAP ist mächtiger und flexibler als ReST. Das ergibt sich schon aus den Details der Definitionen:

SOAP ist ein Protokoll zum Austausch beliebiger XML-Nachrichten und dadurch ein Framework für ein selbst zu implementierendes Protokoll.
SOAP kann mit einem beliebigen Transportprotokoll übertragen werden.
...

Äpfel und Birnen trifft es nicht ganz. Denn man kann ReST mit SOAP abbilden, umgekehrt ist das nicht möglich. Demnach sind die Möglichkeiten von ReST ein Subset derer von SOAP. Der Vergleich von natürlichen und rationalen Zahlen passt besser.

Zitat von onemorenerd

SOAP ist mächtiger und flexibler als ReST. Das ergibt sich schon aus den Details der Definitionen:

SOAP ist ein Protokoll zum Austausch beliebiger XML-Nachrichten und dadurch ein Framework für ein selbst zu implementierendes Protokoll.

Veto! ReST ist noch nicht einmal auf XML festgelegt, weil es sich auf Ressourcen bezieht und nicht deren Repräsentationen. Gegen die Sache mit dem beliebigen Transportprotokoll ist jedoch nichts einzuwenden.

Zitat von onemorenerd

Denn man kann ReST mit SOAP abbilden, umgekehrt ist das nicht möglich. Demnach sind die Möglichkeiten von ReST ein Subset derer von SOAP. Der Vergleich von natürlichen und rationalen Zahlen passt besser.

Jetzt interessiert mich aber, wie du ReST mit SOAP abbilden willst. SOAP sitzt in OSI-Schicht 7 und ReST in der 5, also würdest du ab der Schicht 8 (gibt es nicht) nochmal mit abstrakten Protokollen wie SOAP-HTTP (8), SOAP-TLS (9) und dann evtl. noch SOAP-SOAP (10) anfangen müssen

Keines von beiden ist ein Subset des anderen und mit keinem von beiden lässt sich das andere sinnvoll (!) abbilden. Äpfel und Birnen!

Zitat von AmicaNoctis

ReST ist noch nicht einmal auf XML festgelegt

Habe ich auch nicht behauptet. Mir ging es nicht um "XML-Nachrichten" sondern um "beliebig". Will sagen: Mit SOAP kann man auch andere Verben als die in ReST zur Verfügung stehenden senden.

Zitat von AmicaNoctis

Jetzt interessiert mich aber, wie du ReST mit SOAP abbilden willst.

Ich verpacke die ReST-Nachricht in XML und verschicke sie über HTTP.

POST /foo HTTP/1.1
Host: example.com
Content-Type: application/soap+xml; charset=utf-8
... weitere Header ...

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  <soap:Body xmlns:rest="http://example.com/rest">
    <rest:request>
        ... hier der gesamte ReST-Request eins zu eins eingefügt ...
    </rest:request>
  </soap:Body>
</soap:Envelope>

Zitat von onemorenerd

Ich verpacke die ReST-Nachricht in XML und verschicke sie über HTTP.

Und das findest du sinnvoll? Willkommen in OSI-Level 8

Wenn es danach geht, kann ich SOAP-Nachrichten auch ReSTful übertragen, solange der Webservice auch ohne Sessions und Cookies funktioniert. Hab ich da grad SOAP mit ReST implementiert, weil SOAP ein Subset von ReST ist? Ich glaube nicht und du hast das auch nicht, weil du weit über OSI-Level 5 operierst und damit noch nicht einmal die ReST-Constraints sicherstellen kannst.

Dir ist schon bewusst, dass ReST nichts anderes ist als HTTP mit zusätzlichen Constraints? Das was du grad draus machst ist eine Art ReSTful HTTP-Tunnel über SOAP. Du könntest genauso gut behaupten, dass das IP-Protokoll ein Subset von SOAP wäre, nur weil du Ethernet-Frames in XML codiert übertragen kannst.

Zitat von AmicaNoctis

Und das findest du sinnvoll?

Hab ich nicht behauptet.

Wenn es danach geht, kann ich SOAP-Nachrichten auch ReSTful übertragen

Natürlich kann SOAP ReSTful eingesetzt werden. Aber die Definition von SOAP schreibt das nicht vor.

... solange der Webservice auch ohne Sessions und Cookies funktioniert

Und wenn nicht? Der Webservice mag SOAP sprechen, aber ReSTful ist er dann nicht mehr. q.e.d

ReST ist nur eine Philosophie, ein Satz von Kriterien. Man kann von einer konkreten Implementierung eines Webservice sagen, ob sie ReSTful ist oder nicht. Ganz gleich ob der Webservice SOAP verwendet oder plain old XML oder JSON oder wasweissich.
Es genügt aber nicht, nur die Daten auf der Leitung zu begutachten. Selbst wenn die den Kriterien entsprechen, kann der Server trotzdem Informationen über den Client-Kontext speichern, was eine Verletzung der Kriterien wäre.
Ob eine Kommunikation SOAP ist oder nicht, kann man allein anhand der Nachrichten auf dem Draht feststellen. Man muss nichts über Client oder Server wissen.

Die ReST-Kriterien wirken also beschränkend indem sie vorgeben, welche Rolle (Client, Server) was zu tun bzw. zu lassen hat (Kontext speichern). SOAP ist in dieser Hinsicht nicht beschränkt.

Zurück zu den Vergleichen:
Manche Webservices sind ReSTful, aber nicht alle.
Analog dazu: Manche rationalen Zahlen sind natürlich, aber nicht alle.
Mit Äpfeln und Birnen kannst du das nicht ausdrücken.

Ich hätte vorhin sagen sollen "SOAP ist mächtiger und flexibler als ReSTful SOAP" und statt "die Möglichkeiten von ReST ein Subset derer von SOAP" lieber "ReST bringt Einschränkungen mit sich, die SOAP allein nicht hat".