Hi,
mal ein kleines Status-Update. Also mit Hilfe der Rest-API läßt sich mein Vorschlag einer SteemAuth-API wunderbar umsetzen.

TransactionType: transfer
from,to: UserLoginRequest,UserUseSteemAuthAPI
memo:PublicID oder ein anderer Wert, wie gewünscht

Praktisch ist die PublicID überflüssig und ein Wert wie "Freischaltung" oder so, reichen aus.

1. Problem: Das ganzte in eine performante Abfrage packen. Puh bei der Rest-API muss man sich selber seinen Datenbank-Request basteln. Momentan sieht es nach einer klassischen Schleife aus die gebreakt wird wenn die Werte passen. Aber ich muss testen ob mir es von der Performance hilft mehrere Request in eine Var zu schieben und die zu parsen. Eigentlich schon. Grundsatz Performance Ein Request ist besser als viele und Server-RAM kein Problem mehr:).
2. Problem: Das ganze noch in eine möglichst gute Objekt-Bibiliothek verpacken. Momentan arbeite ich mit mehreren statischen Klassen als Funktion und skalieren in den Klassen dann jeweilige besondere Abfragetypen:

class getMaxTransactions
{
    private $account;
    
    public function __construct (string $account)
    {
        $this->account = $account;
    }
    
    public static function fromAccount($account=NULL)
    {
        $JSON = CallAPI::getJSONResponse('https://api.steemjs.com/getAccountHistory?account='.$account.'&from=99999999999&limit=0');
        return $JSON[0][0];
    }
}

Nur mal als Beispiel wie unsauber das noch ist.

Hat jemand eine Idee wie ich das sauber kapseln könnte. Ich suche ja immer gerne nach neuen Tipps von Pattern-Experten und OOP-Junkies.

getMaxTransactions ist ja sozsusagen eine Methode aber fromAccount auch. Also bei mir. Sozusagen ein SQL-Wrapper für Arme:). Suche immer neue OOP-Ansätze für PHP5.

Als ersten Gedanken für das mit Sub-Objects lösen wollen:

SteemAPI->Auth->getMaxTransactions->fromAccount('thekao') und die SteemAPI bekommt dann erst einmal entweder die Objekt- oder statischen Klassenmethoden.

Naja merke gerade fromAccount kann ich auch der Methode übergeben als string für ne nette case.:). Wäre für neue OOP-Sichtweisen dankbar.