Ankündigung

Einklappen
Keine Ankündigung bisher.

API Driven Development

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • API Driven Development

    Hallo Leute,

    bei mir steht in den nächsten Monaten ein recht großes Projekt an.
    Die Applikation wird hauptächlich als Webservice fungieren um die Kommunikation mit einer bereits teils bestehenden Desktopanwendung zu ermöglichen, wird aber ebenfalls die Präsentation/Manipulation der Daten per Weboberfläche übernehmen.
    Zeitlich ist zuerst die Weboberfläche, danach die integration in die Desktopanwendung geplant.

    Bei meinen Überlegungen/Recherchen bin ich hin und wieder über das Stichwort "Api Driven Development" gestolpert.

    Meine Überlegung:
    Desktopanwendung <---> Webservice <---> Webanwendung
    Die Webanwendung soll also ihre eigene API nutzen.

    Vorteile die ich sehe:
    - ich bin "gezwungen" eine saubere, gut dokumentierte API zu schreiben
    - die API wird - durch den zeitlichen Ablauf - bereits durch die eigene Anwendung getestet
    - DRY ?
    - AJAX-Requests können direkt mit der API kommunizieren

    Nachteile:
    - Performance?
    - unnötige Requests? WebController <--> SerivceController <--> Model/Library ...

    Was sagt ihr zu diesem Vorhaben?

    Sorry falls ich mit dieser Frage im falschen Unterform gelandet bin...

    PS: falls jemand beide Threads gelesen hat. Es geht hier (zum Glück ) _nicht_ um das selbe Projekt wie in meiner Access-Frage
    Hilfe, mein Ball ist umgekippt!

  • #2
    Eine Weboberfläche ist streng genommen eine API. Eine API an eine API zu binden ist nur Mehr-Aufwand, das was du bauen willst ist eine Anwendung mit mutliplen APIs.
    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

    Kommentar


    • #3
      Eine Weboberfläche ist streng genommen eine API.
      Das ist eine GUI, keine API in dem Sinne, wie es hier gemeint ist

      So wie das für mich klingt, wäre es am einfachsten, Du baust eine REST(-ähnliche) API, die Du entweder über Deine Desktop-Anwendung oder per Ajax über Deine Weboberfläche ansteuerst (Geht relativ einfach mit den diversen JS-Frameworks, die es da gibt).

      WebController <--> SerivceController <--> Model/Library
      Was soll hier der Webcontroller und was der Servicecontroller sein?

      Es gibt ja letztendlich zwei Möglichkeiten:
      - Aufbau wie eine Webapplikation (z. B. mit Hilfe des Zend Frameworks oder sonst was) und angesprochen wird das per HTTP wie jede andere Webapplikation auch
      - Aufbau über einen Application-Server, das Ansprechen funktioniert zwar genauso, aber die Applikation muss nicht jedes Mal neu intialisiert werden. Für php gibt es da nanoserv, aber wenn Du diesen Weg einschlagen willst, würde ich eher Java o. ä. empfehlen.

      Kommentar


      • #4
        Jo, genau sowas hab ich vor, xm
        Wie oben erwähnt: Ajax-Requests sollen direkt mit der API kommunizieren.
        Gedanken mach ich mir zur Zeit noch zu den normalen http Requests. Gehen die den Umweg über die API oder wird direkt auf die dahinterliegenden Bibliotheken zugegriffen? Wenn über API schalte ich eine (unnötige?) Schicht dazwischen. Wenn ich die Requests direkt bearbeite wirds womöglich nix mehr mit ner sauberen DRY Implementierung.
        Hilfe, mein Ball ist umgekippt!

        Kommentar


        • #5
          Code:
          +----------------------+
          | MyProject Daemon     | < --- > API Socket Client PHP
          +----------------------+
             ^
             |
             +----- < -- > API Socket Client C++ / Whatever
          ?
          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

          Kommentar


          • #6
            noch zu den normalen http Requests.
            Was sind ajax-Requests anderes?

            Natürlich sollten auch die Desktop-Anwendungen mit der API und nicht mit den darunter liegenden Schichten kommunizieren.

            @tr0y: Was meinst Du damit?

            Kommentar


            • #7
              Ich meine damit das er dann direkt hingehen kann eine API ( im sinne von API ) fürs Web an einen Daemon verbinden lässt ( per PHP ) diese darüber bedient und eine für seine Desktop-Anwendung über eine eigene TCP/IP schnittstelle ohne die Krücke Apache.
              [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

              Kommentar


              • #8
                Achso.. ja, das wäre auch eine Möglichkeit - Oder eben direkt per Application-Server, dann hätte man nur eine Schnittstelle nach außen.

                Kommentar


                • #9
                  Also was meine ich mit normalen http-Requests...
                  Einfaches Beispiel. ExtJS lädt mir ne Tabelle mit Benutzerdaten. Die Daten werden mit nem Ajax-Request an die API geholt.
                  "Normaler" http-Request:
                  Ich verschick ne Mail. "Um diese und jene Aktion durchzuführen klicken sie bitte auf folgenden Link".
                  Nix mehr mit Ajax, nix mehr mit direkter Kommunikation mit der API.

                  Um beim Beispiel des Zendframeworks zu bleiben... Wobei ich damit noch nie wirklich gearbeitet habe und nicht sicher bin ob das hier so funktionieren würde. Aber um meine Gedankengänge zu verdeutlichen sollte es reichen

                  Was meine ich mit Web- und Service-Controller:

                  Code:
                     /application
                        /default 
                          /controllers
                          /views
                        /api 
                          /controllers
                          /models
                          /service-providers
                      /config --> API routing
                  http://example.com/api/edituser?id=1&active=1.... --> ServiceController. Response: Json.
                  Ich klick auf meinen E-Mail-Link: http://example.com/registration/acitivate?code=xxxxxx -->WebController. Response: Ne schöne HTML-Textmessage.

                  Der WebController hat meiner Meinung nach 2 Möglichkeiten:
                  1. Er schickt nen Request an die API: Aktivier mir mal User xy
                  2. Er nimmt das selbst in die Hand.
                  Hilfe, mein Ball ist umgekippt!

                  Kommentar


                  • #10
                    Nix mehr mit Ajax, nix mehr mit direkter Kommunikation mit der API.
                    Warum? Du kannst doch clientseitig den Parameter auswerten und ggf. per Ajax an die API schicken.

                    1. Er schickt nen Request an die API: Aktivier mir mal User xy
                    2. Er nimmt das selbst in die Hand.
                    Wenn es so wäre, warum sollte er es nicht selbst in die Hand nehmen? Hinter den Web- oder dem Service-Controller steht doch eh die Serviceschicht oder ein Model, das das übernimmt?

                    Kommentar


                    • #11
                      Zitat von xm22 Beitrag anzeigen
                      Warum? Du kannst doch clientseitig den Parameter auswerten und ggf. per Ajax an die API schicken.

                      Wenn es so wäre, warum sollte er es nicht selbst in die Hand nehmen? Hinter den Web- oder dem Service-Controller steht doch eh die Serviceschicht oder ein Model, das das übernimmt?
                      Genau darum geht es mir doch
                      Ich kann entweder die dahinterliegende Serviceschicht verwenden um auf den Request zu reagieren oder ich leite den Request (eventuell "umformuliert") an die API weiter, verarbeite den Response und präsentiere das Ergebnis als HTML.

                      Leite ich den Request weiter schalte ich einen Request (eine Schicht) dazuwischen, reagiere ich direkt darauf und verwende die Serviceschicht habe ich 2 Methoden (bzw. Controller) die im Prinzip die selbe Aufgabe übernehmen.

                      Worin ich die Vor- und Nachteile sehe den Request weiter zu leiten hab ich ja schon in meinem Eingangspost erwähnt.
                      Dazu hätte ich gerne ein paar Meinungen. Weiterleiten oder nicht.... Oder eine andere Lösung/ein anderer Aufbau der Applikation?
                      Hilfe, mein Ball ist umgekippt!

                      Kommentar


                      • #12
                        Den Response noch mal auf Serverebene umzuschreibe finde ich irgendwie Wahnsinn. Wenn dann solltest Du für die Serverseite noch direkte API-Zugriffe auf die Daten bereitstellen. API-Responses clientseitig in UI umzuwandeln fände ich ganz spannend, da das aber Javascript voraussetzt ist das natürlich kaum realistisch.
                        [COLOR="#F5F5FF"]--[/COLOR]
                        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                        [COLOR="#F5F5FF"]
                        --[/COLOR]

                        Kommentar


                        • #13
                          Den kompletten API-Response clientseitig umzuwandeln scheint mir wiederrum Wahnsinn zu sein
                          M.m.n. bleibt der Aufwand bzw. das eher umständliche herumhantieren mit den Responses gleich - ich verlagere es nur vom Server auf den Client, häng mir aber zusätzlich die Krücke eines kompletten JS-Renderings ans Bein.
                          Wo siehst du denn den Vorteil? Also mal ganz theoretisch...

                          Ne Schnittstelle für direkte API-Zugriffe wird wohl die beste Lösung sein.
                          Eine Requestunabhängige Library (bzw. mehrere) die alle notwendigen Methoden bereitstellt. Web- und SericeController (um mal bei meinen gewählten Begrifflichkeiten zu bleiben) greifen gleichermaßen darauf zu. Das Einzige was die Controller selbst entscheiden ist in welcher Form der Response erfolgt.
                          Hilfe, mein Ball ist umgekippt!

                          Kommentar


                          • #14
                            Zitat von nikosch Beitrag anzeigen
                            Den Response noch mal auf Serverebene umzuschreibe finde ich irgendwie Wahnsinn.
                            Finde ich gar nicht so wahnsinnig, das erzwingt strikte Entkopplung von Präsentations- und Business-Logik, da in der Präsentationsschicht (Webcontroller, Views) nur "dumme" View Models (aus der JSON-Response) zur Verfügung stehen. Sicher verlangsamt das die Verarbeitung zunächst aber es verbessert die Skalierbarkeit denn ein Nebeneffekt ist dass eine transparente Trennung von Webserver(n) und Applikationsserver(n) ermöglicht wird. Der API-Request (z.B. als Zend_Http_Request) wird dann einfach an den Applikationsserver gesendet anstatt ihn als Parameter an den Service-Frontcontroller zu übergeben.
                            [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
                            [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

                            Kommentar


                            • #15
                              Also wenn ich dich richtig verstehe würdest du das anhand des Beispiels ZF in der Art lösen:

                              PHP-Code:
                              $data getDataFromCurrentRequest();
                              $client = new Zend_Http_Client($url, array('foo' => 'bar'));
                              $client->setParameterPost($data); 
                              $response $client->request(Zend_Http_Client::POST);
                              DoWhatever($response->getBody); 
                              Hilfe, mein Ball ist umgekippt!

                              Kommentar

                              Lädt...
                              X