Eigener Web Service soap oder Rest

Je nachdem, falsche Anfragen z.B. gibt das Framework automatisch zurück. Fehler die in deiner Funktion passieren, da musst doch individuell zurückgeben. Du bestimmst dann den Statuscode !!

hustbaer

@Ibinda100
Bestimmte Dinge machen die HTTP-Service Frameworks normalerweise selbst.
z.B. wenn ein komplett unbekannter Pfad reinkommt, dann wird das Framework einen 404 zurückschicken.
Wenn der Pfad bekannt ist, aber das Verb nicht passt, dann wird oft automatisch ein "405 Method Not Allowed" zurückgeschickt.
Wenn das Framework Authentifizierung unterstützt wird es normalerweise auch selbst "401 Unauthorized" zurückschicken.
Je nachdem wie das Framework mit MIME Types umgeht evtl. auch "406 Not Acceptable" oder "415 Unsupported Media Type".
"411 Length Required" wird normalerweise recht tief unten im HTTP-Stack gehandelt, wird also auch automatisch gehen.
"413 Payload Too Large" wird auch automatisch gehen wenn das Framework entsprechende Einstellungen für solche Limits hat.
"414 URI Too Long" ebenso automatisch.
usw.

Wenn man Codes wie "409 Conflict" generieren möchte muss man sich normalerweise selbst darum kümmern.
Bzw. wenn man ne URL im Format ".../items/{itemId}" unterstützt, der Client die URL ".../items/42" anfordert, es aber kein Item 42 gibt und man daher 404 zurückschicken will, dann muss man sich natürlich auch selbst darum kümmern. Da der Handler-Code den man für solche URLs schreibt dann ja erstmal mit itemId=42 aufgerufen wird. Und dieser Handler-Code muss dem Framework halt irgendwie mitteilen dass er ne Antwort mit Status 404 zurückschicken möchte.

Von den von dir aufgelisteten werden auch ein paar automatisch gehen (z.B. "500 Internal Server Error" oder "505 HTTP Version Not Supported"), andere machen bei Webservices eher keinen Sinn (z.B. die ganzen Codes für Proxies oder WebDAV), und wieder andere wird man manuell auslösen müssen (z.B. "501 Not Implemented").

Grundsätzlich sind HTTP Status Codes bei Webservices aber eher uninteressant. Um die ganzen "low level" Fehler kümmert sich das Framework, und für Fehler auf Applikationsebene findet man kaum passende Codes. Daher ist die übliche Vorgehensweise wohl für solche Fehler Status 400 zurückzugeben, und dabei ein Dokument mit einem eigenen Fehlercode + einer verständlichen Fehlerbeschreibung zurückzuschicken.

Sofern es möglich ist REST zu nehmen ist REST immer vorzuziehen.

Bei manchen komplexen APIs ist REST nicht machbar weil es zu komplex wird, aber sofern es ohne sich komplett zu verrenken möglich ist, immer REST nehmen.

Shade@work schrieb:

Bei manchen komplexen APIs ist REST nicht machbar

Echt ? Es kann sein dass REST nicht machbar ist ? Wieso das denn ? Schlimmstenfalls kann man doch alles als Json senden. Das sind doch beliebig Verschachtelungen möglich.

Wie ist das eigentlich bei SOAP mit http Status Codes. Soll man die auch setzen ?

Also den einzigen Vorteil den ich bei Soap sehe ist der Vorteil der WS-Security. Klar die WSDL ist schon cool. Sie beschreibt den Webservice sehr gut.
Banken setzen wohl gerne SOAP ein. Warum weiss ich nicht genau.

hustbaer

Ibinda100 schrieb:

Shade@work schrieb:

Bei manchen komplexen APIs ist REST nicht machbar

Echt ? Es kann sein dass REST nicht machbar ist ? Wieso das denn ? Schlimmstenfalls kann man doch alles als Json senden. Das sind doch beliebig Verschachtelungen möglich.

Bei REST geht es um mehr als nur HTTP+JSON. Genaugenommen haben weder HTTP noch JSON direkt mit REST zu tun. Es ist bloss so dass RESTful Webservices sehr oft mit HTTP und JSON umgesetzt werden.

Im Prinzip bildest du bei REST alles als Objekte ab, wobei jedes Objekt ne URL hat. Um mit den Objekten zu arbeiten werden dabei folgende Methoden angeboten:
POST um ein neues Objekt in einer Collection zu erzeugen
PUT um ein Objekt zu überschreiben (bzw. zu erzeugen falls es noch nicht existiert)
GET um ein Objekt abzufragen (zu lesen)
PATCH um ein Objekt zu ändern
DELETE um ein Objekt zu löschen

Der Unterschied zwischen POST und PUT beim Erzeugen von neuen Objekten ist im Prinzip, dass du das Objekt bei PUT bereits mit seinem Namen ansprichst, d.h. du musst den Namen kennen bevor du das Objekt erzeugen kannst. Existiert schon ein Objekt mit diesem Namen, dann wird es überschrieben. (Bzw. falls die Objekte read-only sind, dann endet der Call halt mit einem Fehler.)
Bei POST gibt man üblicherweise den Namen der Collection an, also wenn du z.B. Bücher verwaltest und ein neues Buch anlegen willst, dann müsstest du POST /books sagen oder halt PUT /books/1234 .

Und der Unterschied zwischen PATCH und PUT beim Ändern von Objekten ist, dass man bei PUT das gesamte Objekt (alle Felder/Eigenschaften) mit neuen Werten überschreibt, während man bei PATCH selektiv änderungen machen kann. D.h. mit PATCH kann man sowas wie "object.property += 2" mit einem atomaren Aufruf machen.

BTW: Falls dir PATCH kein Begriff sein sollte, lies z.B. dashier: http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

Im Prinzip war's das dann.

Was hier z.B. abgeht ist Support für Transaktionen. Oder Support für Bulk-Operationen. Oder Support für kompliziertere Queries.

Bei den meisten Dingen wird es vermutlich möglich sein die erforderliche Funktionalität auf REST abzubilden, aber es kann eben nötig sein dazu bestimmte Verrekungen zu machen, wie Shade schon geschrieben hat.

Als Beispiel vielleicht ... Konten. Du hast mehrere Konten, und willst ne Möglichkeit anbieten einen Betrag von einem Konto auf ein anderes zu überweisen. Sagen wir von Konto /accounts/1 auf Konto /accounts/2 .
Mit zwei Operationen könnte man das ganze relativ einfach machen: zuerst Konto /accounts/1 PATCHen (quasi "balance -= 123") und dann /accounts/2 PATCHen ("balance += 123").
Ist bloss doof wenn das ganze unterbrochen wird, denn dann fehlt Geld. Und Transaktionen gibt's ja nicht, also können wir uns damit auch nicht behelfen.
Ein POST auf die Collection /accounts kommt auch nicht in Frage, da POST auf Collections nur verwendet werden sollte um neue Objekte darin zu erzeugen.
Am ehesten kommt vielleicht noch ein PATCH auf /accounts hin. Keine Ahnung ob das üblich ist, aber es wäre eine Möglichkeit.

Eine andere Möglichkeit wäre ein neues "transfer" Objekt zu definieren. Also z.B. die Collection /transfers mit Einträgen /transfers/1 , /transfers/2 usw. Dann könnte man eine Überweisung dadurch bewerkstelligen dass man die entsprechenden Daten an die Collection /transfers POSTed.

Und was Bulk-Operationen angeht: Überleg dir mal wie du einem REST Service mitteilen willst dass du in deiner CD Sammlung das Genre von allen CDs die momentan Genre "Rock" haben zu "Pop/Rock" ändern willst. Auch hier könnte man sich vermutlich wieder mit PATCH auf eine Collection behelfen, aber auch das ist weniger schön und umständlicher als man es gerne hätte.

Wie du siehst wird das alles recht schnell recht aufwendig. Speziell auch was die Dokumentation angeht. Denn überall wo du PATCH verwendest, musst du definieren wie die "Änderungsscripts" aussehen die mit PATCH gesendet werden können. Überall wo POST zum Anlegen von neuen Objekten verwendet wird im Prinzip ebenso.
Hast du dagegen ein SOAP Service, kannst du beliebige Operationen definieren die beliebige Nebeneffekte haben dürfen. Und dank WSDL musst du das genaue Format nicht nochmal extra dokumentieren in dem Objekte oder Requests verschickt werden.

----

Bessere Beispiele für wo REST schlecht passt fallen wir jetzt gerade keine ein. Falls jemand eines hat wäre ich auch interessiert.

Auf der Client Seite wird bei uns Javascript verwendet. Ich hab zwar jetzt eine SOAP Javascript Library gefunden. Aber die implementiert nicht WS-Security. Kennt einer eine SOAP Bibliothek die WS-SEcurity implementiert. Gibt es sowas überhaupt. Falls es das nicht gibt, wäre das ein Ausschlusskriterium für SOAP. Dann müsste ich Rest verwenden....

ich hab nur das gefunden. Aber das ist fuer Node.js was ja serverseitig ist.

http://www.codeproject.com/Articles/373317/Ws-js-A-Ws-implementation-for-Node-js

Alternative wäre diese javascript Soap library zu verwenden

http://www.codeproject.com/Articles/12816/JavaScript-SOAP-Client

und dann das ganze mit https übertragen. Dann hat man auch seine Security, wenn auch nicht die angedachte WS-Security.

Was haltet ihr davon ?

hustbaer

Ibinda100 schrieb:

Falls es das nicht gibt, wäre das ein Ausschlusskriterium für SOAP. Dann müsste ich Rest verwenden....

WTF?

WTF ?? versteh ich jetzt nicht..

hustbaer

Ich verstehe den Schluss "SOAP geht nicht, also REST" nicht.

SOAP standardisiert bestimmte Dinge wie z.B. wie Objekte als XML formatiert werden, wie die XML Dokumente auszusehen haben die Procedure Calls beschreiben, wie das ganze mit anderen Protokollen wie z.B. HTTP zusammenspielt etc.
SOAP kümmert sich dabei nicht darum welche Semantik die Procedure Calls haben.

REST ist so ziemlich das exakte Gegenteil. Es beschreibt ein Konzept wie man APIs aufbauen kann. Dabei gibt es keinen formalen Standard und es werden keine genauen Vorgaben gemacht wie z.B. Objekte formatiert werden müssen.

Soweit ich es verstehe könnte man sogar ein RESTful SOAP Webservice machen. Zumindest fällt mir erstmal kein Grund ein warum das nicht gehen sollte.

Und daher finde ich den Schluss "SOAP geht nicht, also muss ich REST machen" ... unsinnig.

welchen Nutzen hat eigentlich die Base64 codierung. Es werden nur die 64 Zeichen benutzt die in jedem Zeichensatz der welt lesbar sind. Gut. Aber was bringt mir das für die Übertragung. Und vorallem wie wird es wieder dekodiert. Man weiss ja gar nicht welchen ursprünlichen Zeichensatz man hatte. Oder steht das im http dabei ?

hustbaer

Mit Base64 kann man beliebige Daten über einen Kanal transportieren, der nur sicherstellt ANSI Text korrekt und unverändert zu transportieren. Und solche Kanäle gibt es - z.B. kann man in SMTP nicht einfach beliebige Bytefolgen übertragen. Das selbe Problem gibs dann genau so beim Abspeichern von Daten in bestimmten "Containern". Also z.B. Filenamen, da kannste auch viele Zeichen nicht verwenden. Oder versuch mal beliebige Binärdaten in einem XML File abzuspeichern.

Lässt sich aber alles nachlesen, z.B. auf Wikipedia.