Technologie für Webservice mit unterschiedlichen Clients (Plattformunabhängig)

[GstaGsta]

Guten Morgen,

ich habe vor einen Webservice zu schreiben, auf den von unterschiedlichen Clients zugegriffen werden soll. Es soll für den Webservice keinen unterschied machen, welcher Client informationen anfordert. Die Clients sind alle auf unterschiedlichen Plattformen (PC: Win, Unix, Mac...; Mobile: Android, iOS, Win Mobile; ...)

Nun meine Frage:

Mit welcher Technologie setze ich das am besten um? Am liebsten wäre es mir den Service unter .NET mit C# zu schreiben und das ganze unter eiem IIS hosten zu lassen, da die Services später auf Windows Azure laufen.

Funktioniert das ganze mit CGI? Und wenn ja wie sieht denn die Kommunikation dann aus?

Liebe Grüße
GstaGsta

[Christian Marquardt]

ich habe vor einen Webservice zu schreiben, auf den von unterschiedlichen Clients zugegriffen werden soll. Es soll für den Webservice keinen unterschied machen, welcher Client informationen anfordert.

Das ist Sinn und Zweck eines Webservice

Mit welcher Technologie setze ich das am besten um?

Egal, sofern die Clientanwendungen mit einer Programmiersprache arbeiten, die einen Webservice ansprechen können, ist es wurscht, mit welcher Sprache der Webservice an sich implementiert ist

Funktioniert das ganze mit CGI?

Die Frage ist unverständlich. CGI hat mit einem Webservice nichts zu tun

[fanderlf]

Ich denke die beste Interoperabilität hast Du wenn Du einfach Json over Http verwendest. SOAP sollte wohl so ein standard werden, nur leider funktioniert das nicht so 100%. Zumindest hat unser Webservice Team schon einige Schwierigkeiten damit gehabt. Ehrlich gesagt reicht Json eigentlich auch zum Serialisieren und es gibt in jeder halbwegs gängigen Programmiersprache Möglichkeiten Json zu de-/serialisieren. Im Endeffekt schickt ein Webservice ja auch nur Text hin und her... wie eigentlich alles im Web

[Christian Marquardt]

Ich denke die beste Interoperabilität hast Du wenn Du einfach Json over Http verwendest. SOAP sollte wohl so ein standard werden, nur leider funktioniert das nicht so 100%. Zumindest hat unser Webservice Team schon einige Schwierigkeiten damit gehabt. Ehrlich gesagt reicht Json eigentlich auch zum Serialisieren und es gibt in jeder halbwegs gängigen Programmiersprache Möglichkeiten Json zu de-/serialisieren. Im Endeffekt schickt ein Webservice ja auch nur Text hin und her... wie eigentlich alles im Web

Dann muss jeder Client wissen, wie die Schnittstelle zu implementieren ist. Der Vorteil beim Webservice ist ja gerade, dass der Webservice dies über seine WSDL mitteilt (und die IDEs den Code dazu automatisch erzeugen). Auch bietet ein Webservice mehr als nur den Transport der Daten (bsp. Funktionausaufrufe). Des Weiteren funktioniert SOAP eigentlich ganz gut (Java). Als Alternative würde sich REST anbieten, wenn das SOAP Probleme macht. JSON over HTTP benötigt einen Webserver und keinen Webservice

[fanderlf]

In der Theorie kann das so sein, aber wir hatten schon diverse Clients die mit SOAP nicht umgehen konnten, weil SOAP anscheinend nicht über alle Programmiersprachen/frameworks hinweg gleich implementiert ist (so wie das eigentlich bei fast allen standards ist). REST wäre eine Möglichkeit, das teilt dem Benutzer dann sogar mit welche Aktionen er auf dem geladenen Objekt ausführen kann. Eine Dokumentation benötigt man für einen öffentlichen Webservice sowieso immer, deswegen sehe ich es jetzt nicht kritisch. Nur dass evtl. das Erstellen des Clients ein klein wenig schneller geht.