Im Beispiel werden die Auth-Daten ja in der Plugin-Config angegeben… ich habe dort also die Logindaten eines Admin-Users eingegeben. Ist das korrekt? Wieso wird hier nicht der API-Key aus dem Headless-Sales-Channel genutzt?
Das Beispiel ist wohl nur für die Admin-API ausgelegt… aber wie bekomm ich das für die Sales-Channel-API hin?
mit dem Response meines Admin-API-Calls kann ich ohnehin nix anfangen …
Scheint mir am auslesen deiner Response zu liegen. Was in deiner Response steht sind die Header-Informationen des Requests und nicht der eigentliche Body.
grundsätzlich werden erstmal nur die Hauptdaten einer Entität ausgeliefert, die du anfragst. Heißt z.b. nur die Produktdaten. Zusätzliche Daten, die mit dem Produkt assoziert sind, müssen nicht mit einem extra Call geholt werden. Du kannst bei der Anfrage auch angeben, dass die mitgeladen werden sollen. Hier Shopware 6: Reading entities findest du ein Beispiel JSON, wie z.B. Produkte zu einer Category mitgeladen werden. Dies lässt sich analog auf Produkte und Hersteller übertragen.
Es lässt sich jetzt sicherlich argumentieren, dass man doch immer den Hersteller zu einem Produkt braucht, aber wir haben das aus Performance Gründen bewusst so gestaltet. Es gibt eben halt auch immer Szenarien, wo dies nicht benötigt wird.
das Beispiel von dir versteh ich nicht ganz, das hat weniger was mit meinem Fall zu tun. Leider ist die Doku hier echt dürftig… ich will kein Limit und auch keine Anzahl von Herstellern…
ich will einfach alle Daten in einem Call dabei haben
genau, das musst du dann im Body als JSON String mitgeben.
{
"associations": {
"manufacturer": {}
}
}
Du musst die Associations ja nicht limitieren oder sonstiges. Ein leeres Objekt reicht an der Stelle dann. Du findest die Daten dann in der Response unter dem Key „included“.
Falls dir das json:api Schema nicht zusagt, kannst du auch einfach den Accept Header auf „application/json“ setzen. Shopware 6: Admin api authentication
Soweit ich das verstehe, sind das aber Filter/Parameter für den search-Endpoint. Sprich jede Entity hat auch eine search Route, dafür machst Du anstelle eines
GET /api/v1/product
ein
POST /api/v1/search/product
Dann, wie schon beschrieben, mit mit associations als Payload im Body des POST Request und die manufacturers werden dann innerhalb _ included _ gelistet.
Das Ganze macht aber nicht so viel Sinn, wenn Du eine ungefilterte Produktliste aufrufst. _ included _ hängt nicht an jedem Produkt, sondern ist ein Key im Response (während die Produkte unter dem Key data gelistet sind). Sprich, während manufacturer nach wie vor am Produkt als “relationship” mit der ID als Referenz hängt, werden die manufacturer-Daten unter include gelistet. Damit brauchst du dann aber zumindest keinen extra Request mehr machen, sondern kannst dir alles aus einem Response zusammen suchen. Oder du verwendest zusätzliche Filter, um für jedes Produkt genau die Daten zu abzurufen, die du sehen willst - dafür dann natürlich mit mehreren Requests.
Da hat das einwandfrei funktioniert, es direkt als URL-Parameter anzugeben…
aber in PHP über einen GET bekomm ich es einfach nicht hin. Geht das hier nicht bei einem GET? Oder unterscheiden sich hier die Sales-Channel-API und die Admin-API?
Ja, die beiden unterscheiden sich in Nutzung und Einsatzzweck. Wie die Name schon andeuten, hat die eine den Fokus auf´s Backend, die andere auf das Frontend:
The SalesChannel-API is part of our API family. It allows access to all sales channel operations, such as creating new customers, customer login and logout, various cart operations and a lot more.
It’s ideal if you want to build your own storefront.
Das von dir verlinkte Howto behandelt die Shopware/Admin API. Für diese benötigt man den OAuth-Token zur Authentifizierung und wenn du die associations nutzen willst, dann nur per POST über den search Endpoint.
Die Implementierung eines Clients für die Sales-Channel-Api ist einfacher, da hier keine Authentifizierung nötig ist. Man brauch lediglich einen Header mit dem API Access Key des jeweiligen Sales-Channel für jeden Request
Wie auch immer, du kannst das Ganze auch in einer anderen Sprache implementieren. Das Beispiel behandelt PHP mit ein SW-Plugin, aber normalerweise rufst du die APIs nicht über ein SW-Plugin auf (selbst in dem Howto wird davon abgeraten, dass über ein Plugin zu machen.).
wieso sollte man die API nicht von einem SW-Plugin aus aufrufen? Was spricht dagegen?
Wenn ich eine Anbindung an eine Warenwirtschaft machen muss, bleibt mir ja nichts anderes übrig. Außer ich hoste irgendwo ein externes “Tool”, was dann wiederum mit SW kommuniziert… Aber das ist eigentlich Blödsinn.
ps: mit dem Search-Endpoint hat das mit Associations nun geklappt… wusste nicht, dass das nicht für GET geht
Michael Telgmann