turk porno porno escort rokettube
Ergebnis 1 bis 5 von 5

Thema: ZF kommuniziert mit Objective-C

  1. #1
    Erfahrener Benutzer Avatar von itsame69
    Registriert seit
    21.09.2009
    Beiträge
    1.148
    Thanks
    0
    Thanked 4 Times in 4 Posts

    Standard ZF kommuniziert mit Objective-C

    Hallo,

    ich beginne in wenigen Wochen mit der Implementierung eines völlig neuen System, d.h. ich hab eine grüne Wiese vor mir. Dabei müssen mobile Endgeräte (iPhone/iPad) mit einem Server kommunzieren. Für die Endgeräte wird natürlich Objective-C verwendet, für das Backend möchte ich ZF einsetzen (wahrscheinlich noch eine Version < 2.0).

    Folgende Randbedingungen:

    - es wird eine überschaubare Anzahl (<100 pro Minute) kleiner Datenpakete (einige KB) hin- und hergeschickt.
    - die Last fällt zu genau definierten Zeitpunkten an
    - das System ist nicht offen, d.h. es erfolgt "nur" eine hausinterne Kommunikation
    - Daten müssen wohl verschlüsselt übertragen werden (https)
    - Das Backend muss die Daten einerseits den mobilen Clients zur Verfügung stellen, andererseits aber auch ein Web-Portal beliefern (also XML/JSON und HTML)

    Mein erster Gedanke war natürlich REST. Habt ihr ähnliches schon gemacht? Wenn ja, welche Art der Kommunikation bietet sich da an, oder ist eine RESTful Applikation eh eine brauchbare Lösung?

    lg
    Christian

  2. #2
    Erfahrener Benutzer Avatar von SeKrebs
    Registriert seit
    05.02.2011
    Beiträge
    1.599
    Thanks
    1
    Thanked 58 Times in 46 Posts

    Standard

    Mein erster Gedanke war natürlich REST. Habt ihr ähnliches schon gemacht? Wenn ja, welche Art der Kommunikation bietet sich da an, oder ist eine RESTful Applikation eh eine brauchbare Lösung?
    REST setzt in der ursprünglichen Idee direkt auf HTTP auf. Insofern stellen sich die anderen Fragen eigentlich gar nicht

    - es wird eine überschaubare Anzahl (<100 pro Minute) kleiner Datenpakete (einige KB) hin- und hergeschickt.

    Da REST auf HTTP aufsetzt kann es für GET und HEAD direkt bekannte Caching-Mechanism einsetzen. Aber ok, is jetz bei 100 Request eh net so wild
    - die Last fällt zu genau definierten Zeitpunkten an
    Ist eigentlich in diesem Kontext keine echte Frage. Wenn sich der Server langweilt, vielleicht bisschen was zu spielene geben?
    - das System ist nicht offen, d.h. es erfolgt "nur" eine hausinterne Kommunikation
    Macht doch nichts
    - Daten müssen wohl verschlüsselt übertragen werden (https)
    HTTP -> HTTPS Aber denke, das ahntest du schon
    - Das Backend muss die Daten einerseits den mobilen Clients zur Verfügung stellen, andererseits aber auch ein Web-Portal beliefern (also XML/JSON und HTML)
    Via Content-Negotation kein Problem.

    REST ist eigentlich DAS Internet, wie es ursprünglich gedacht war: Es gibt eine handvoll Verben, die das tun, was sie versprechen, und solange kein Aktion (Request) ausgeführt, der modifizierend wirkt (also nicht GET oder HEAD) führt ein Identifier (URI, URL) immer zu exakt ein und dem selben Dokument. Das macht "Zufallsseiten" etwas kompliziert, aber ansonsten grad für APIs eigentlich wie geschaffen. Und was anderes willst du ja offenbar nicht machen

    "KingCrunchs kleine Welt" -- Blog
    The problem with rats leaving a sinking ship is that they usually do it by gnawing holes in the bottom.

  3. #3
    Erfahrener Benutzer Avatar von ice-breaker
    Registriert seit
    29.03.2008
    Ort
    Steinbach/Taunus
    Beiträge
    1.862
    Thanks
    0
    Thanked 9 Times in 5 Posts

    Standard

    Kann mich da SeKrebs nur anschließen nur den letzten Punkt würde ich erweitern: Das Web-Portal kann auch selbst wiederum die REST-API nutzen, das wird häugif gemacht. So ist die zentrale Komponente des ganzen System einfach der REST-Webservice und jeder Anwendungsteil nutzt nur diesen. Vorteil: Webseite und mobiler Client werden sich immer automatisch identisch verhalten, es kann nicht ein Bug nur bei einem sein und nicht beim anderen, Fehler werden also schneller gefunden. Genauso ist auch das Caching usw dann einfacher, da nur der REST-Webservice cachen müsste (falls ihr es doch eines Tages braucht) und nicht mehr das Webportal und der REST-Service für ObjectiveC - Inkonsistenzen sind also unmöglich.
    "Die Wahrheit entgeht dem, der nicht mit beiden Augen sieht." -Orici

  4. #4
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Ganz nebenbei laufne die Sachen auch nicht auseinander und die Wartung beider "Frontends" wird auch besser sichergestellt. Die API von Twitter ist da so ein Beispiel. Anfangs wurden API und Webfrontend unterschiedlich behandelt und die API vernachlässigt. Später wurde sich dazu entschlossen, das Web auch an die API anzubinden, wodurch diese first class citizen wurde und seitdem gibt es auch wesentlich weniger Probleme mit der API.
    Neues Projekt: zandman.de - Status: WIP




  5. #5
    Erfahrener Benutzer Avatar von SeKrebs
    Registriert seit
    05.02.2011
    Beiträge
    1.599
    Thanks
    1
    Thanked 58 Times in 46 Posts

    Standard

    Kann mich da SeKrebs nur anschließen nur den letzten Punkt würde ich erweitern: Das Web-Portal kann auch selbst wiederum die REST-API nutzen, das wird häugif gemacht. So ist die zentrale Komponente des ganzen System einfach der REST-Webservice und jeder Anwendungsteil nutzt nur diesen.
    Tuts das nicht irgendwie, bloß nicht mit anderem Content-Type im Response (und der Tatsache, dass Browser von selbst kein PUT oder DELETE verwenden ). Mit Content-Negotation kann man dann neue Seiten wahlweise als neuen Request, oder via AJAX und JSON laden.

    Ich befürchte, wir reden vom Selben
    "KingCrunchs kleine Welt" -- Blog
    The problem with rats leaving a sinking ship is that they usually do it by gnawing holes in the bottom.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •