7 Antworten zu diesem Thema

[Mike Haid]

Hallo,

 

wie kann ich den per Api eine Artikel aus einer Kategorie entfernen??

 

DELETE /Products(1)/ProduktCategories (mit oder ohne $filter)

 

geht leider nicht.

 

Gruß

Mike

[Marcus Gesing]

Das geht über die API leider nicht.

[Mike Haid]

Das geht über die API leider nicht.

 

Autsch! Das ist aber schade. Findet es ihr nicht ein wenig Inkonsequent das Anlegen / bzw. Löschen von  Artikel zu erlauben, aber jedoch nicht bei den Artikel/SubQuerys.

 

Somit ist es sinnlos einen Artikel per Api anzulegen, sofern ich ihn nicht komplett (d.h. mit allen Attributen / Bildern etc) per Api anlegen kann.

 

--

Wozu?

 

Hier ein kleines Beispiel aus unserer Praxis, weshalb wir sowas immer mal wieder benötigen.Ein Restpostenhändler bekommt ständig neue Ware. Diese muss innerhalb kürzester Zeit Online verfügbar sein. Hierzu hat er 3 Mitarbeiterinnen die nichts anderes tun als die neue Ware im ERP anzulegen, bepreisen, in die entsprechenden Kategorien einzuteilen und ein Foto zu hinterlegen. Ein Klick später muss die Ware bei den verschiedenen Kanälen online sein (Shop/Amazon/EBay etc).
Diesen Mitarbeiterinnen können wir es nicht zumuten dieses jeweils mit Hilfe des Online-Backends zu erledigen. 
 

Nachdem die Artikel online sind überwacht unser System automatisch die Abverkäufe aus den verschiedenen Kanälen und entfernt die Artikel nach dem kompletten Abverkauf automatisch aus den OnlineSystemen (es macht auf keinen Sinn die Artikel in der Datenbank stehen zu lassen, da diese wahrscheinlich eh nie wieder kommen). 
Im Falle von Retouren werden die Artikel automatisch wieder eingestellt (ggfs. als Sonderangebote / B-Ware etc). 

 

--

 

Aber:

Das ist jetzt aber kein Beinbruch, ich kann ja über die Datenbank gehen... Nur ist es halt sicherheitstechnisch nicht wirklich schlau, den SQL Server im Internet freizugeben.

 

Eine Anregung:

Zwar nicht ganz RESTFul like... Aber wäre es nicht sinnvoll die Api um eine Möglichkeit zu erweitern um einen SQL-Befehl / eine Abfrage direkt an die Datenbank zu senden.  

 

Ich stelle mit da sowas wie:

POST http://xyzshop.de/odata/v1/DBQuery im Content würde dann z.B. "select top 10 * from Country" stehen

als Ergebnis dann eben ein JSON mit dem Resultset des DBServers

 

bzw.

 

POST http://xyzshop.de/odata/v1/DBExecute   Im Content dann z.B. "delete/update/insert .. wat auch immer"

als Ergebnis die entsprechende Erfolgsmeldung bzw. Fehlermeldung
 

Somit hätte man immer eine Ausweichmöglichkeit bei nicht unterstützen API Funktionen und wäre extrem flexibel.  

 

 

Gruß

Mike

[Marcus Gesing]

...Aber wäre es nicht sinnvoll die Api um eine Möglichkeit zu erweitern um einen SQL-Befehl / eine Abfrage direkt an die Datenbank zu senden.  

 

Nein. Das ist ein no-go. Zu unsicher, Gefahr von Selbstsabotage, Zugriff auf Daten möglich, auf die tunlichst nicht via API zugegriffen werden sollte und und und...

[Mike Haid]

 

 

 

Nein. Das ist ein no-go. Zu unsicher, Gefahr von Selbstsabotage, Zugriff auf Daten möglich, auf die tunlichst nicht via API zugegriffen werden sollte und und und...

 

 

 

Ermal vorneweg ... kein Stress... :-) Nur vielleicht eine nette Diskussion.

 

Ich hatte schon vermutet, dass dieses Argument kommt.

 

Für mich ist das kein no-go, Erstmal gehe ich davon aus, dass die API eh nix für den "Ottonormaluser" ist. Wer damit rumspielt, sollte auch schon ein wenig Ahnung haben. 

 

Die Gefahr der Selbstsabotage ist doch heute eh schon gegeben, versuchen Sie mal Delete ..odata/v1/Settings(irgendeineID) usw. schießt auch u.U. den gesamten Shop ab.

 

Logischerweise können wir über die Sicherheit bei den Paymentdaten reden. Hier liegt das Problem aber sicherlich an odata bzw. des unverschlüsselten Respone.

 

Prinzipiell würde ich eh sagen... "keine API ohne https"

 

Ich würde die DB-Direkt Funktion nicht standardmäßig freigeben,  sondern nur wenn der User es explizit anklickt. Da könnten Sie dann ja auch einen Haftungsausschluss einfügen.

 

Es geht mit nur um die Flexibilität alle Anforderungen unserer Kunden zu erfüllen können, wir sind ja auch nur Dienstleister.  Welche aber noch weit über das reine Anlegen von Artikel hinaus geht (Shippment Informationen, Trackingnummern, BtoB Shops etc.).

Letztendlich haben wir als ERP-Dienstleister doch häufig ein mächtiges Wort bei der Shopauswahl mitzureden und ich mag nicht immer Magento empfehlen müssen :-( Deswegen gebe ich auch noch nicht auf.

 

Klar ich gebe nun einfach die DB frei und gut. Aber ob das im Sinne des Erfinders ist??? Oder gar sicherer?

 

Ihr habt ein tolles Produkt... und die Api kann schon mehr wie die von diversen anderen Shops.. aber so ganz 100% ist es noch nicht.

 

So long

Mike

 

 

btw: Wir sind zwar nur eine ganz kleine Butze, arbeiten u.a. sehr viel im medizinischen / militärischen Bereich und da müssen wir regelmäßig durch die diversen Zertifizierungen/Audits und eine der Vorgaben ist fast immer "Zugriff auf alle Daten", Offenlegung von allen Softwarefunktionen etc.

[Marcus Gesing]

Ich würde das so nicht machen. Ich würde das Absetzen von nativem SQL über das Shopping-System grundsätzlich nicht ermöglichen, auch nicht optional, und das schließt auch die Wartungsseite im Backend mit ein. So etwas würde ich, wenn es denn notwendig sein sollte, strikt trennen, d.h. in eine externe Anwendung auslagern. Deletes über die API führen "nur" zum Löschen von Daten oder im Falle von Primär-Entitäten zur Gelöscht-Markierung, schließen aber - im Gegensatz zu SQL - die Gefahr inkonsistenter Daten aus. SSL ist im Backend steuerbar, betrifft aber nur den Datenaustausch, also in Bezug auf die API und die Datenbank einen relativ kleinen Sicherheitsbereich. Natürlich fehlen in der API noch Dinge. Dabei denke ich aber vor allem an Sachen wie die Web-Hooks.

[Mike Haid]

Klar verstehe ich schon. Wäre ja nur so ein Notnagel, bis die API so weit ist.

Ich würde immer eine API vorziehen eben um inkonsistente Daten zu vermeiden, da habe ich mit den diversen osCommerce-forks schon so meine negativen Erfahrungen und viel Gefrickel hinter mir.

 

So nebenbei: Gibt es irgendwo eine Doku wie man ein Plugin erstellt (dann muss ich nicht soviel rumprobieren), wäre für ein anderes Projekt interessant.

[Marcus Gesing]

Die Doku ist in Mache. Ein paar Beiträge dazu gibt's im Englischen Forum, z.B. hier.

 

Am einfachsten ist es wahrscheinlich, man kopiert sich ein Plugin, welches seinem am nächsten kommt,

schmeißt nicht benötigtes raus und legt dann learning by doing und Schritt für Schritt los. Beim Kopieren eines Plugins

nur darauf achten, dass man die ProjectGuid in der Projektdatei manuell ändert.