Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: API für modified

    karsta.de

    • Experte
    • Beiträge: 3.048
    Re: API für modified
    Antwort #60 am: 18. August 2020, 11:31:47
    @Torsten
    Insgesamt ist das hier wieder eines der Themen, wo alle mitreden und helfen wollen, aber keiner, auch nur ein einziger hat es seit 2017 mal geschafft sich hier zu beteiligen: Mithilfe der Community erwünscht - Dokumentation des auto_include Modul Systems

    Interessant. Ist wohl komplett hier im Forum untergegangen. Auch in Eurem Blog hab ich dazu keinen Eintrag gefunden.
    Scheint ja inzwischen nun hinfällig geworden zu sein, da Gerhard ganz klar geäußert hat, dass das wohl rausfliegen wird.
    @RobinTheHood
    Ein entscheidender Grund warum wir keine neuen autoincludes aufnehmen ist, dass das System aus der Not heraus geboren wurde und sich nun im Alltag als völlig ungeignet erweist. Ja, wir werden ein neues Hook System bringen.

    Gruss Gerhard

    BG Karsta
    Marktplatz - Eine große Auswahl an neuen und hilfreichen Modulen sowie modernen Templates für die modified eCommerce Shopsoftware

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.185
    • Geschlecht:
    Re: API für modified
    Antwort #61 am: 18. August 2020, 11:34:15
    Dass das System komplett überarbeitet wird ist klar, aber das nächste Major-Release (3.0.0.0) wird sicherlich nicht mehr dieses Jahr kommen.
    Würde also schon noch lohnen die Seite nochmal anzugehen. ;-)

    Grüße

    Torsten

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.743
    • Geschlecht:
    Re: API für modified
    Antwort #62 am: 18. August 2020, 14:04:37
    [...]
    Insgesamt ist das hier wieder eines der Themen, wo alle mitreden und helfen wollen, aber keiner, auch nur ein einziger hat es seit 2017 mal geschafft sich hier zu beteiligen: Mithilfe der Community erwünscht - Dokumentation des auto_include Modul Systems
    [...]

    Seltsam, kannte ich auch nicht.

    Übrigens hat meine Wenigkeit nicht die geringste Ahnung wie man was in's Wiki schreibt.
    Mich hat schon immer gewundert, daß man, einmal eingeloggt, nicht auch dort eingeloggt ist und im Trac ebenso.
    Ich war bislang zu faul mich damit genau zu beschäftigen und wollte auch nicht mehrere Login-Credentials für modified verwalten.
    Was muß man tun um im Wiki zu schreiben ?

    Noch kurz:
    Euer Verhältnis zu fishnet geht mich nichts an und auch meine Wenigkeit hat kurz mit Unverständnis gestockt, als das Forum im Zusamenhang mit der Kritik an mangelnder Zusammenarbeit genannt wurde.
    Ich bitte euch nur zu überdenken vielleicht doch noch einmal aufeinander zuzugehen, wäre ansonsten echt Schade. fishnet ist aus irgendwelchen Gründen sauer auf euch, sicher auch nicht ohne Grund, und er ist halt sehr direkt.
    Und GTB z.B. - ohne das jetzt als Vorwurf zu meinen und diskutieren zu wollen - kann nach meiner Erfahrung sehr lapidar schnippisch rüberkommen, sodaß man sich vor den Kopf gestossen fühlen kann.
    Will das auch nicht hier ausweiten, will nur sagen, wir sind doch alle erwachsen und sollten uns nicht benehmen wie alte Ehepartner die sich über Jahrzenhte gegenseitig Wunden beigebracht haben die sie nie besprochen und somit nie geheilt haben. :-)

    Gruß,
    noRiddle

    Gulliver72

    • Mitglied
    • Beiträge: 191
    • Geschlecht:
    Re: API für modified
    Antwort #63 am: 18. August 2020, 14:09:40
    @ alle die am Wiki arbeiten wollen

    unten rechts gibt`s den Link "Bearbeiten"  ;-)

    Bin auch gerne dabei

    VG Bert

    Edit sagt gerade, dass der Login mit den Forumsdaten nicht funktioniert :-(

    Edit sagt aber auch, dass man sich nach Registrierung auch anmelden kann
    wäre schöner, wenn man im Forum und Wiki ohne extra Registrierung eingeloggt sein kann

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.185
    • Geschlecht:
    Re: API für modified
    Antwort #64 am: 18. August 2020, 15:12:55
    [...]
    Insgesamt ist das hier wieder eines der Themen, wo alle mitreden und helfen wollen, aber keiner, auch nur ein einziger hat es seit 2017 mal geschafft sich hier zu beteiligen: Mithilfe der Community erwünscht - Dokumentation des auto_include Modul Systems
    [...]

    Seltsam, kannte ich auch nicht.
    [...]

    Huch!? Gebt uns mal einen Tipp, wie wir Themen noch besser hervorheben können, wenn eine Fixierung seit 2017 nicht ausreicht? :nixweiss:

    [...]
    Übrigens hat meine Wenigkeit nicht die geringste Ahnung wie man was in's Wiki schreibt.
    Mich hat schon immer gewundert, daß man, einmal eingeloggt, nicht auch dort eingeloggt ist und im Trac ebenso.
    Ich war bislang zu faul mich damit genau zu beschäftigen und wollte auch nicht mehrere Login-Credentials für modified verwalten.
    Was muß man tun um im Wiki zu schreiben ?
    [...]

    Es gab mal mehrere Ansätze von Bridges von SMF zu MediaWiki, aber die haben leider alle nicht funktioniert und sind nun alle archiviert.
    Wir hätten gerne eine funktionierende Bridge, dass man sich im Wiki nicht separat anmelden muss, aber derzeit ist das leider der Fall, genau wie beim Trac.

    Grüße

    Torsten

    Gulliver72

    • Mitglied
    • Beiträge: 191
    • Geschlecht:
    Re: API für modified
    Antwort #65 am: 18. August 2020, 15:50:28
    [...]
    Wir hätten gerne eine funktionierende Bridge, dass man sich im Wiki nicht separat anmelden muss, aber derzeit ist das leider der Fall, genau wie beim Trac.
    [...]

    Habt ihr das schon geprüft? Ist gepflegt für Version 2.0.16

    https://github.com/SimpleMachines/smf-mw-auth

    VG Bert

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.185
    • Geschlecht:
    Re: API für modified
    Antwort #66 am: 18. August 2020, 16:53:46
    Hallo Bert,

    ja, das kennen wir auch. Das war ja das Modul hinter "Extension:SMF Auth Integration". Allerdings hatten wir es zuletzt mit Version 1.14 getestet und nun gibt es Version 1.15. Wir schauen uns das nochmal an, Danke für den Tipp.

    Nachtrag: Auch Version 1.15 scheint nicht zu funktionieren. Als wenn es ein Problem mit der SSI-Einbindung im MediaWiki gibt...

    Grüße

    Torsten

    snocer

    • Fördermitglied
    • Beiträge: 312
    Re: API für modified
    Antwort #67 am: 20. August 2020, 08:25:14
    Wenn ich es noch einmal aufrufe. Was ist den genau geplant, eine RestFullApi, eine RestApi oder eine APIXML.? Die erste Variante scheidet ja wahrscheinlich aus, weil hier ja dann auch alle das gleiche OS etc. verwenden müssten um die API ja jedem Hosting Inhaber per Dienst zur Verfügung zu stellen. Eine APIXML würde sich ja relativ schnell umsetzen lassen für alle Wawi`s die eine XML Import/Export beherrschen.

    Nachfolgend nur mal ein kleiner Ansatz für das Adressbuch getestet, muss natürlich noch mit zwei weiteren Tabellen verknüpft werden (Relation) um alle relevanten Daten in die XML zu schreiben. Land /Name, USt.-ID als Wert usw. Das war gestern zu meinem Spaß mal in einer Stunde erledigt.

    Code: PHP  [Auswählen]
    <?php

    //Erzeugen oder überschreiben der Eport XML Datei
    $datei = fopen("export.xml", "w") or die("Es ist nicht möglich die Datei zu öffnen!");
    //Datenbankverbindung herstellen
    $pdo = new PDO('mysql:host=localhost:3306;dbname=testshop', 'root', '');
    $sql = "SELECT * FROM address_book";

    //Daten in XML wegschreiben
    $daten = "<?xml version='1.0' encoding='iso-8859-1'?>\n";fwrite($datei, $daten);
    $daten = "<address_book>\n";fwrite($datei, $daten);
    foreach ($pdo->query($sql) as $row) {
      $daten = "<address>\n";fwrite($datei, $daten);
      $daten = "<address_book_id>".$row['address_book_id']."</address_book_id>\n";fwrite($datei, $daten);
      $daten = "<customers_id>".$row['customers_id']."</customers_id>\n";fwrite($datei, $daten);
      $daten = "<entry_gender>".$row['entry_gender']."</entry_gender>\n";fwrite($datei, $daten);
      $daten = "<entry_company>".$row['entry_company']."</entry_company>\n";fwrite($datei, $daten);
      $daten = "<entry_firstname>".$row['entry_firstname']."</entry_firstname>\n";fwrite($datei, $daten);
      $daten = "<entry_lastname>".$row['entry_lastname']."</entry_lastname>\n";fwrite($datei, $daten);
      $daten = "<entry_street_address>".$row['entry_street_address']."</entry_street_address>\n";fwrite($datei, $daten);
      $daten = "<entry_suburb>".$row['entry_suburb']."</entry_suburb>\n";fwrite($datei, $daten);
      $daten = "<entry_postcode>".$row['entry_postcode']."</entry_postcode>\n";fwrite($datei, $daten);
      $daten = "<entry_city>".$row['entry_city']."</entry_city>\n";fwrite($datei, $daten);
      $daten = "<entry_state>".$row['entry_state']."</entry_state>\n";fwrite($datei, $daten);
      $daten = "<entry_country_id>".$row['entry_country_id']."</entry_country_id>\n";fwrite($datei, $daten);
      $daten = "<entry_zone_id>".$row['entry_zone_id']."</entry_zone_id>\n";fwrite($datei, $daten);
      $daten = "<address_date_added>".$row['address_date_added']."</address_date_added>\n";fwrite($datei, $daten);
      $daten = "<address_last_modified>".$row['address_last_modified']."</address_last_modified>\n";fwrite($datei, $daten);
      $daten = "</address>\n";fwrite($datei, $daten);
    }
    $daten = "</address_book>\n";fwrite($datei, $daten);
    $pdo = null;
    $sql = null;

    fclose($datei);

    ?>

    das geht vielleicht auch noch kürzer, aber lässt sich so später auch noch gut anpassen bzw. erweitern wenn sich an der DB Struktur von modified mal was ändert. Gibt eine schöne wohlgeformte XML Datei als Ausgabe. Der Ausgabe Pfad ist jetzt in dem Beispiel noch nicht festgelegt. Schreibt somit erst einmal in die Root. Der Benutzer kann dann natürlich noch über eine View im Backend von modified seine DB Daten eintragen, die er von seinem Hoster erhält. Auch das Encoding für die XML Ausgabe kann auf utf-8 geändert werden oder x-beliebig.

    cu snocer

    PS: für die API Interessierten.

    [EDIT Tomcraft 20.08.2020: Code formatiert.]

    RobinTheHood

    • Experte
    • Beiträge: 204
    • Geschlecht:
    Re: API für modified
    Antwort #68 am: 20. August 2020, 11:26:21
    Ich würde eine REST API empfehlen mit modularen Endpoints je API Version, Entity und für beliebige Output-Formater. JSON ist "state of the art", aber natürlich kann man dann noch beliebige weitere Formater wie XML, etc. hinzufügen. Dazwischen würde ich möglicherweise ein ORM Datenbank Model setzen, damit man für jede Entity und jeden Endpoint die Daten einheitlich an die Formater übergeben kann. Wenn man möchte kann man das Ergebnis auch noch in eine Datei umleiten. Dann könnten die Routes z. B. wie folgt gebildet werden. Das muss man natürlich zuvor einmal grob durch-spezifizieren, damit man ein Gefühl dafür bekommt, wie man die Queries genau bilden möchte. Auf jeden Fall wäre ich stark für einen modularen Ansatz.

    GET /api/1.1.2/xml/product/1234
    ...
    POST /api/1.3.2/json/search/product
    {
        "page": 1,
        "limit": 5,
        "name": '%Kugelschreiber%'
        "includes": {
            "product": ["id", "name"]
        }
    }

    Response
    {
        "total": 30,
        "data": [
            {
                "name": "Roter Kugelschreiber",
                "id": "12345",
            },
            {
                ....
            }
        ]
    }   

    snocer

    • Fördermitglied
    • Beiträge: 312
    Re: API für modified
    Antwort #69 am: 20. August 2020, 13:52:37
    Auch eine RestApi wäre ein gangbarer Weg. Sehe hier nur das Problem, wenn hier auch Hoster sind, das die Output Dateien ja in jedes Hosting geschrieben werden müssen.  Zum Beispiel: ./export/modifiedapi.xml oder beliebig.

    Ich persönlich würde sogar ein RestFullApi bevorzugen wenn ich der alleinige Hoster wäre. Dann brauche ich keine Crons etc. für die einzelnen Host sonder kann das schön über Webdienste abwickeln und der weiter Vorteil wäre jede Änderung im Shop wird sofort synchronisiert.

    Aber da steht dann  wieder das Problem, einer Suse, einer CentOS, einer RedHeat, einer Debian, einer Ubuntu usw. Die Pfade sind da teilweise zu unterschiedlich um das alles simpel zu synchronisieren. Ich persönlich verwende für meine Webserver nur Debian. Für eine RestFullApi wie beschrieben, kann ich bei mir gleich alle DB für alle Kunden sofort die XML Files erstellen mit allen Werten wenn gewünscht. Das ist eine Minuten Sache und der Benutzer / Shop Anwender muss keinen Cron einrichten etc.. Weil eben als Webservice auf dem Server/n installiert. Hier soll das Team mal sagen wo sie der Meinung sind wo die Reise hingehen soll. Die von mir zuerst genannte Lösung mit allen was eine Wawi sich aus dem Shop holen kann, mit leichter Anpassbarkeit ist in max. 4 Tagen mit vielen Kaffepausen umgesetzt. RestFullApi sollte noch schneller machbar sein, weil ja alles über den Webservice gesteuert werden kann. Hier müssen Termine her und Anforderungen klar umrissen werden, dann sollte so ein Projekt schnell durch sein (kann schnell durch sein). Nur will ja keiner was machen, wenn die Vorgaben fehlen, was ich auch verstehen kann. Soviel Zeit hat keiner übrig.

    cu snocer

    PS: Torsten danke für die Korrektur. Ich habe das heute morgen nur mal kurz eingeworfen vor meinem Arbeitsbeginn.
    Aber man (ich) sollte eben auch auf Ordnung achten. Danke.

    karsta.de

    • Experte
    • Beiträge: 3.048
    Re: API für modified
    Antwort #70 am: 20. August 2020, 14:47:07
    !Off Topic!
    [...] ist in max. 4 Tagen mit vielen Kaffepausen umgesetzt. [...]

     8-) Und wie viel Schachteln Zigaretten. :mrgreen:

    BG Karsta

    RobinTheHood

    • Experte
    • Beiträge: 204
    • Geschlecht:
    Re: API für modified
    Antwort #71 am: 20. August 2020, 15:00:43
    @snocer
    Ich muss an dieser Stelle einmal anmerken, dass ich die von dir angesprochene Problematik mit den Verzeichnissen auf den jeweiligen Server-Konfigurationen (noch) nicht verstehe. Mein Verständnis einer (REST/SOAP) API ist, dass die Software (WAWI/FIBU/etc.) die auf Daten vom Shop über eine API zugreifen möchte (oder Daten verändern möchte) einen API Call über das HTTP(S) Protokoll an den Shop macht und dann eine Antwort vom Server bekommt. In meiner Vorstellung gibt es da keine Problematik mit Verzeichnissen auf dem Server des Shops. Aber ich vermute, dass ich noch etwas nicht ganz verstanden habe aus deiner letzten Nachricht.

    Mit besten Grüßen
    Robin

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.743
    • Geschlecht:
    Re: API für modified
    Antwort #72 am: 20. August 2020, 15:20:42
    @RobinTheHood
    Warum genau ein ORM ?
    ORMs (für PHP z.B. Doctrine) sind nach meinen Informationen ziemlich eingeschränkt und DB-Zugriff benötigt die API doch nur auf die shop-eigene DB und die ist MySQL.
    Was verstehe ich nicht ?

    Gruß,
    noRiddle

    snocer

    • Fördermitglied
    • Beiträge: 312
    Re: API für modified
    Antwort #73 am: 20. August 2020, 16:04:37
    @snocer
    Ich muss an dieser Stelle einmal anmerken, dass ich die von dir angesprochene Problematik mit den Verzeichnissen auf den jeweiligen Server-Konfigurationen (noch) nicht verstehe. Mein Verständnis einer (REST/SOAP) API ist, dass die Software (WAWI/FIBU/etc.) die auf Daten vom Shop über eine API zugreifen möchte (oder Daten verändern möchte) einen API Call über das HTTP(S) Protokoll an den Shop macht und dann eine Antwort vom Server bekommt. In meiner Vorstellung gibt es da keine Problematik mit Verzeichnissen auf dem Server des Shops. Aber ich vermute, dass ich noch etwas nicht ganz verstanden habe aus deiner letzten Nachricht.
    [...]

    Hallo Robin,

    ich versuche mal meine Gedanken darzustellen.
    Jede Wawi hat ja so Ihre eigenen DB Felder die befüllt werden können. Für den Import in die WaWi ist ja jede Wawi selbst verantwortlich. Ich dachte deswegen wir stellen aus der modified DB nur die Daten zur Verfügung die eine WaWi auch verarbeiten kann. Unsere RestApi oder APIXML stellt eben dann auch nur die Daten zur Verfügung die benötigt werden.
    Artikeldaten, Bilder, Metadescription, Bestellungen, Kunden dazu etc., dadurch beschränken wir schon mal die Last.
    Die WaWi die sich anbinden möchte, kann die generierte XML Datei entsprechend seiner DB Struktur mappen für den Import und Export so bleiben die Systeme schön getrennt und es werden fehleranfällige Wechselwirkungen vermieden (ANSI, UTF-8 etc.). XML sollte jede Wawi beherrschen, ansonsten ist xml auch leicht zu konvertieren. Hat auch den Vorteil die modified Api egal wie kann relativ schnell und günstig so gebaut werden, das auch Lagerbestände von diversen Distris schnell eingelesen werden können. Natürlich auch neue Artikel etc. darüber möglich. Dafür verwenden wir dann entweder den ./import Ordner und mappen den externen Ablageort oder lassen den Distri im Import direkt ablegen. Zeitgesteuert oder automatisch wird dann der Import Ordner gecheckt und die Änderungen eingelesen.

    cu snocer

    PS: schnell geschossen, muss noch etwas Geld heute verdienen. :-)
    RestJSON statt SOAP, würde ich ja auch vorziehen, wenn es nur um einen Shop und oder gleiche Serverkonstellation gehen würde. Aber da es zu viele WaWi`s auf dem Markt gibt, dachte ich eher an eine flexible und schnell erweiterbare Lösung, falls sich bei modified was ändert. Und durch die XML Struktur sollte es jedem auch möglich sein, seine WaWi entsprechend anzupassen. Selbsterklärende Begrifflichkeiten. Der Api Call Aufruf ist doch im Grunde das gleiche, nur wird die Datei dann eben erst zu Anfrage Zeit generiert und nirgends abgelegt, weil die Antwort sofort an das Anfragende System geht. Durch die lokale Ablage sah ich nur den Vorteil, das eben auch der Anwender Shop Betreiber selbst noch Einfluss nehmen kann falls er mehr Informationen an seine WaWi übertragen kann und möchte.

    RobinTheHood

    • Experte
    • Beiträge: 204
    • Geschlecht:
    Re: API für modified
    Antwort #74 am: 20. August 2020, 16:40:32
    @ noRiddle
    Im Grunde hast du Recht. Ein ORM wäre technisch nicht nötig. Es würde nur dabei helfen, weniger Programmcode schreiben zu müssen, das Ganze mit einem  Static Analysis (wie z. B. psalm.dev) auf eine gewisse Korrektheit prüfen zu können und fehlerfreieren Code zu schreiben. Nachteil wäre hier vielleicht die Performance, da man einen weiteren Layer hat. Vorteil ist, dass man den Code automatisch auf Fehler prüfen kann. Ich kann aber nicht sagen was besser ist, ohne das ich da vorher Tests sehe oder schreibe. Wollte nur in den Topf werfen, was ich machen würde, aber es geht auch anders und auch anders gut.

    @ snocer
    Ok, ich hab gerade überlegt und dachte 🧐 ... vielleicht muss man da noch einen Schritt zurück gehen. Vielleicht ist es da besser, wenn man wüsste, was die Anbieter, die sich an den Shop anbinden möchten/sollen gerne hätten. Und da muss ich sagen, habe ich nur wenig Erfahrung/Kenntnis. Ich merke gerade, dass ich also gar nicht für eine bestimmte Technologie werben kann. 😇

    Beste Grüße
    Robin
    10 Antworten
    12263 Aufrufe
    30. Dezember 2010, 10:29:00 von Tomcraft
    0 Antworten
    2188 Aufrufe
    31. Juli 2018, 21:02:11 von marketeer
    12 Antworten
    6528 Aufrufe
    02. Juli 2018, 10:44:56 von Joklin
               
    anything