Moin. ich schreibe gerade für mich und die Kollegen, und vielleicht auch für andere Interessenten, eine Doku über Shopware Playground Storefront. Damit man das an einem realistischen Umfeld testen kann und die Doku-URL’s nicht nur Fake sind, wäre es cool wenn man eine Demo-Api von SW haben kann. Also eine die auch alle anderen nutzen können. Sowas wie “demoapi.pg.shopware.com”. Und die dann natürlich mit Demodaten gefüllt ist. Klar, könnte ich auch meine eigene Instanz erstellen, aber wer weiss wie lange ich die warten kann :-/ Das wäre bestimmt auch ein prima Hürdensenker für noobs. Danke.
Ps, die API ist spitze! Aber die Doku ist das Schlimmste ever. Könnt ihr den Verantwortlichen bitte eine Aufgabe geben die er/sie/divers gewachsen ist? Im Namen der Produktivität und des Weltfriedens. Selbst Google fragt mich ob er die “englische” Seite aus dem “polnischen” ins “deutsche” Übersetzen soll Das hat doch niemand verdient , die Api ist so super, dass ich vor Freude im Dreieck springen könnte und die Doku bringt mich direkt in die Klappse. Genie und Wahnsinn. Ying und Yang. Mett und Zwiebel.
danke für dein Feedback. Die Dokumentation wird sicherlich nochmal ausgebaut/überarbeitet Eine Demo Instanz haben wir bisher nicht geplant, da der Playfround ja für alle frei zur Verfügung steht und wir den Prozess um eine neue Instanz zu erstellen relativ einfach gehalten haben.
Wie du schon geschrieben hast kannst du aber natürlich einen neuen Verkaufskanal anlegen und den x-sw-access-key zusammen mit deiner Instanz URL in deine Dokumentation aufnehmen. Größere Wartungsarbeiten sind hier nicht zu erwarten.
Ich habe damit keine Probleme und es ist alles super erklärt? Und wenn dich Google fragt ob er die Seite aus den polnischen ins Deutsche übersetzen soll? Keine Ahnung was Ihr da immer fabriziert, aber mich hat Google noch nie gefragt und die Doku ist ok.
Nur ein paar Beispiele : (https://docs.shopware.com/en/shopware-platform-en/using-the-storefront-api/introduction?category=shopware-platform-en/using-the-storefront-api) Hier heisst es, es wird keine Authentification benötigt „The Storefront API has no authentication“. Eine Zeile später wird dann von einem „x-sw-access-key“ gesprochen, der immer dabei sein muss, er wäre z.B. wichtig für einen Customer „header“. Ok, customer will ich ja nicht machen. was denkt mein Gehirn zuerst? Antwort: keine Auth nötig. Dann mache ich eine Api-Anfrage, natürlich ohne x-sw-access-key, weil das für mich wie eine Auth aussieht. Wodurch wird diese Denke Unterstützt? Weil die Serverantwort auf „/api/v1/catalog“ ist „Missing Authorization header“. Ahhh, und nach hin und her probieren komme ich darauf, dass Mit Customer header, nicht irgendein Feature gemeint ist, sondern der Request Header, und nach weiterem raten, dass dieser auch bei nicht Kundensensitiven Sachen, also überall, gebraucht wird. „aber das steht doch da“… ja, interpretationssache
Weiteres Beispiel:„The Storefront API does only require the client_id, which you can find in the Administration -> Sales Channel“. Ja das wäre doch mal intessant zu wissen, dass diese client_id die API Zugangs-ID ist. Ausserdem, wüsste ich jetzt nicht, dass „x-sw-access-key“ und „API Zugangs-ID“ zusammengehören, wo doch von client_id gesprochen wird, könnte man annehmen man müsse nur die API Zugangs-ID übersenden, so wie ein Token.
Weiteres Beispiel API-urls, bitte bedienen sie sich:
@brettvormkopp Ehm … Keine Ahnung wie du dir das vorstellst …
Aber eine Authenfizizierung verbindet man hier in der Regel eben mit einem Login oder ähnl. Also wenn man das schon nicht versteht … Dafür kann ja nun Shopware nix
Und ein Header oder dergleichen wird natürlich benötigt, ist doch absolut logisch. Ansonsten könnte ja jeder eine Abfrage auf deiner API machen. Also wenn man dafür ein Verständnis hat sollte das eigentlich direkt Klick machen ^^
Bzgl. client_id, axxess-key & API-Key gebe ich dir Recht. Da könnte man die Doku definitiv überarbeiten und das ganze klarer ausdrücken. Denn letztendlich sind die drei Dinge derselbe API-Key.
Bzgl. der API-URL’s: Joa … Und das Problem liegt wo? ^^
Es gibt eine Produkt URL für die Storefront API und eine für das Backend. /api/v1/product ist indem Beispiel die Backend URL mit den Filtern. Die Filter funktionieren aber genauso in der Storefront.
Kann man ja auch einfach ausprobieren.
Verbesserungen gibt es immer. Ich würde jetzt aber auf keinen Fall soweit gehen und sage, dass die Doku schlecht ist, ganz im Gegenteil …
@Shopwareianer Als Dokuschreiber geht man immer vom DAU aus. Man schreibt Unpersönlich. Nutzt eine Sprache. Warum gerade englisch, german first. Wenns der deutsche nicht schnallt, dann der Engländer doch erst recht nicht. Gerade auch bei Shopware ist doch die Anzahl der Nicht-Programmierer hoch. Diese Leute muss man doch begeistern. Top Beispiel ist ja auch Backend->Dokumentation->Storefront-Api -> Ergebnis: https://docs.shopware.com/en/shopware-platform-en/core-components/using-the-storefront-api
PS Frage: Der Auth über “x-sw-access-key” bzw der Api Zugangs-ID, die darf doch öffentlich sein, oder muss ich die verstecken? Weil sie ist ja keine Auth mit der ich Cataloge löschen kann, sonder nur die Identifikation für den richtigen "Sub"shop, oder @Jens_K ?
@shopwareianer nutze jquery mit Ajax und createElement. Hatte mal einen ähnliche Technik mit mongoDB, nodejs als Katalog umgesetzt. Da werden ich wieder ansetzen um ein Ratz-Fatz-Shop zu bauen der schneller ist als SpeedyConsalez. Voraussetzung hierfür ist aber bei mir, dass der x-sw-access-key öffentlich sein darf stehe da gerade aufn Schlauch.
Also die API ist nicht für Nicht-Programmierer. Eigentlich logisch.
Und warum German first? In der Programmierung wird prinzipiell immer Englisch gesprochen, um es zugänglich für jeden zu machen.
Und Deutsche schnallen es ja eigentlich, du jetzt vielleicht nicht direkt - Aber hey, schließ von dir nich auf alle anderen
Also ich habe jetzt wie gesagt mit der API überhaupt keinerlei Probleme gehabt. Aber ich bin ehrlich: Wenn man hier schon Probleme hat das ganze mit dem Auth zu verstehen, dann musst du eben noch ein wenig mehr lernen oder dich generell in solche Dinge einarbeiten. Aber eine API ist eben eine Schnittstelle für Entwickler, nicht für irgendwelche Endkunden/Benutzer/Nicht-Entwickler
Die Storefront API kann nichts löschen, oder editieren nur lesen und filtern. Okay … einige Dinge anlegen wie bspw. einen Kunden. Okay löschen auch - Aber nur ein Item im Warenkorb bspw. Eben das was für die Storefront nötig ist. Aber steht ja auch alles in der Doku. Aktuell gibt es ja sowieso noch nicht so mega viele Endpunkte.
Man kann aber jetzt nicht daher gehen und über die Storefront API einen Sales Channel, Kategorie oder Kunden löschen.
API’s sind nicht mein Tagesgeschäft und ausgebildeter Programmierer bin ich auch nicht. Was soll aus mir noch mal werden hahaha.
Orientiert man sich an anderen Dokus (ausser z.B. Instagram, die sind noch grausamer) dann gibt es viele Tolle Beispiele wie man es macht, z.b. THREEjs, jQuery, Bootstrap, MongoDB, NodeJS, PHP etc… Ich kann aus eigener Erfahrung sagen, dass es einige Personen um mich herum gibt, die über Software XY, z.B. auch Shopware erlernt haben zu scripten und zu programmieren. Das bietet sich doch an, diese jungen begeisterten Menschen gleich an die eigene Software zu binden. So funktioniert das in Unis mit Software-Lizenzen, gratis Schulungen etc. und diese Studenten bringen dann die Softwarekenntnis mit in die Firma wenn sie fertig sind und Chef kauft Software. Frage, wissen das die Leute die noch nie eine Uni von innen gesehen haben, dass man so Tech-Evangelisten heranzieht? Oder will man das nicht? Mhhh.
Klar, wenn du nicht wirklich Entwickler oder Neulinge ansprechen willst, dann ist die Doku noch evtl. etwas mager. Klar.
Aber aktuell geht es ja auch viel mehr darum neue Ansätze zu finden, neue Ideen zu sammeln usw. Und das kommt in diesem speziellen Fall nun einmal mehr vom Entwickler.
Bspw. “Hey, überdenkt doch nochmal die Filterung in der API” oder wat weiß ich. Damit hat ja am Ende der Endnutzer nix am Hut.
Aber komm … die Doku ist nun wirklich nicht schlecht … Da gibts es bedeutend schlechtere Dokus …
Aber ich stimme zu, dass die Doku nach außen hin mit das wichtigste bei einem Open Source Projekt ist - Da ist natürlich Luft nach oben mit vielen Beispielen usw.
Aber Abwarten und Tee trinken. Steckt ja alles derzeit noch in den Kinderschuhen und aktuell werden wohl eben eher die Entwickler angesprochen und nicht die Endkunden
Aber du kannst dir ja in der Zeit schon einmal Vue.js zur Gemüte führen. Da haste massig zum lernen. Webpack/Babel/ES6/Vue.js usw. den ganzen Kram.
Das Backend wird ja hier auf Vue.js aufbauen.
Das hat doch niemand verdient , die Api ist so super, dass ich vor Freude im Dreieck springen könnte und die Doku bringt mich direkt in die Klappse. Genie und Wahnsinn. Ying und Yang. Mett und Zwiebel.
Eine Demo Instanz haben wir bisher nicht geplant, da der Playfround ja für alle frei zur Verfügung steht und wir den Prozess um eine neue Instanz zu erstellen relativ einfach gehalten haben.
