Dann brauchen sie auch garnicht den Service anbieten, wenn sie die Möbel anbieten aber die Images nicht ?!
Ist in dem Fall die TXT lösung nicht schneller (oder die .json)
?
Redis speichert alles als JSON ab, somit müssen sie nur die Daten mit Cronjob ins JSON einfügen und können es ganz einfach ausgeben. Läuft 100%%%% schneller ?
#Update
Die API wurde erweitert. Die Badges haben nun das entsprechende Image dazu.
Ebenso wurde ein "error-handling" Mechanismus implementiert.
Caching
Server seitiges caching ist vorhanden, jedoch wird empfohlen, dass der Nutzer selber die results cached.
Beispiele
https://api.habfiles.net/badges/nope
https://api.habfiles.net/badges/com/nope
Euer JSON ist komisch aufgebaut. Wieso nicht gleich so:
{
"msg": "Page not found"
"status": 404,
"data": LEERES JSONARRAY
}So sparen sich die Nutzer einige Arbeit.
Wenn alles Erfolgreich war, dann msg "success", "status" 1337 oder sowas und halt die Daten in "data" rein.
^ Mit Handy geschrieben lui
Mfg
Euer JSON ist komisch aufgebaut. Wieso nicht gleich so:
Code{ "msg": "Page not found" "status": 404, "data": LEERES JSONARRAY }So sparen sich die Nutzer einige Arbeit.
Wenn alles Erfolgreich war, dann msg "success", "status" 1337 oder sowas und halt die Daten in "data" rein.
^ Mit Handy geschrieben lui
Mfg
Eine einfache if() Abfrage ob der key "error" existiert reicht.
if (isset($response['error'])) {
/**
* Etwas ist schiefgelaufen.
*
* $response['error']['message'] -> um herauszufinden, wo genau
* der Fehler liegt.
*/
}nice project 
Eine einfache if() Abfrage ob der key "error" existiert reicht.
PHPif (isset($response['error'])) { /** * Etwas ist schiefgelaufen. * * $response['error']['message'] -> um herauszufinden, wo genau * der Fehler liegt. */ }
Ist schon ein bisschen doof zu parsen, wenn es bei einer erfolgreichen Anfrage ein Array, aber bei einem Error ein Objekt ausgibt. Es sollte in beiden Fällen das gleiche Schema ausgeben, z. B.:
Wenn erfolgreich:
{
"error": "",
"data": [...]
}Wenn Error:
{
"error": "Du hast Error :(",
"data": []
}Somit ist es viel, viel einfacher, es in statisch typisierten Sprachen wie C# und Java zu parsen.
Ist schon ein bisschen doof zu parsen, wenn es bei einer erfolgreichen Anfrage ein Array, aber bei einem Error ein Objekt ausgibt. Es sollte in beiden Fällen das gleiche Schema ausgeben, z. B.:
Wenn erfolgreich:
Code{ "error": "", "data": [...] }Wenn Error:
Code{ "error": "Du hast Error :(", "data": [] }Somit ist es viel, viel einfacher, es in statisch typisierten Sprachen wie C# und Java zu parsen.
Danke für die Kritik. Wir lassen es aber vorerst mal wie es ist. Vielleicht passen wir das in der Zukunft noch an.
Warum denn das Error Objekt mitliefern wenn es nicht unbedingt immer Notwendig ist?!
Setzt das wie bereits von koksal baba empfohlene 'status' Objekt ein.
Damit lässt sich übrigens auch Traffic sparen für ohnehin fixe Fehlermeldungen.
Durch die Methode lässt sich generell einiges an Traffic und RAM einsparen.
Warum denn das Error Objekt mitliefern wenn es nicht unbedingt immer Notwendig ist?!
Setzt das wie bereits von koksal baba empfohlene 'status' Objekt ein.
Damit lässt sich übrigens auch Traffic sparen für ohnehin fixe Fehlermeldungen.
Durch die Methode lässt sich generell einiges an Traffic und RAM einsparen.
Stimmt, das Error Objekt muss nicht immer mitgesendet werden. Und der erste Schritt zum Traffic sparen, wäre erstmal Serverseitige Kompression anzumachen
Vielversprechendes Projekt.
Freue mich auf mehr Einblicke und wünsch euch weiterhin
viel Glück.
Domain top!
Stimmt, das Error Objekt muss nicht immer mitgesendet werden. Und der erste Schritt zum Traffic sparen, wäre erstmal Serverseitige Kompression anzumachen
Auf kosten der CPU Leistung, da muss man halt abrechnen was einem wichtiger ist - Bandbreite oder Leistung.
in dem Fall da sie bei Blazingfast sind, haben sie unlimited traffic also wäre CPU Leistung wichtiger - brauchst also keine Kompression.
Auf kosten der CPU Leistung, da muss man halt abrechnen was einem wichtiger ist - Bandbreite oder Leistung.
in dem Fall da sie bei Blazingfast sind, haben sie unlimited traffic also wäre CPU Leistung wichtiger - brauchst also keine Kompression.
Sie haben zwar unlimited traffic aber nicht unlimited bandwidth.
Die werden zwar sowieso nicht so ein hohes Trafficaufkommen produzieren aber es geht ums Prinzip.
Der "client" der API möchte ja auch etwas sparen..
Ausserdem kommts ziemlich stark aufs gzip level an.
Level 1 (von 9) im Vergleich zu gar keiner Kompression bewirkt schon "Wunder" und ist sogar recht Ressourcensparend.
Fazit: Es gibt in meinen Augen keinen Grund gzip nicht zu verwenden..
EDIT: Wer an einem kleinen Benchmark interessiert ist, für den dürfte die folgende Seite interessant sein. Oder er führt einfach selbst Benchmarks durch (was bei ner Mietvm aber oft zu verfälschten Ergebnissen führt). https://www.rootusers.com/gzip-vs-bzip2-…nce-comparison/
Jungs, Linux und NGINX bitte
Oder eben noch besser: FreeBSD und NGINX 
PHP
if (isset($response['error'])) {
/**
* Etwas ist schiefgelaufen.
*
* $response['error']['message'] -> um herauszufinden, wo genau
* der Fehler liegt.
*/
Danke für eure Verbesserungsvorschläge, aber wir lassen alles es erstmal so wie es ist da wir finde es wäre besser wie wir es machen.
Bitte sucht euch einen kompetenten Berater.
Ich kann verstehen, dass ihr uns villeicht nicht traut. Das ist die kaputte Retroszene.
Aber jetzt mal wirklich.. Das ist ein sehr sehr schlechter Stil.
Das kann man machen um Fehler zu fangen, man sollte es sich aber keinesfall angewöhnen so regulär seinen Programmcode zu schreiben.
Übertrieben dargestellt wäre das einfach folgendes:
#include <iostream>
int main(void)
{
if((1+1) == 2)
{
std::cout << "1+1=2" << std::endl;
}
return 0;
}anstelle von:
#include <iostream>
int main(void)
{
std::cout << "1+1" << (1+1) << std::endl;
return 0;
}Alles anzeigenSie haben zwar unlimited traffic aber nicht unlimited bandwidth.
Die werden zwar sowieso nicht so ein hohes Trafficaufkommen produzieren aber es geht ums Prinzip.
Der "client" der API möchte ja auch etwas sparen..
Ausserdem kommts ziemlich stark aufs gzip level an.
Level 1 (von 9) im Vergleich zu gar keiner Kompression bewirkt schon "Wunder" und ist sogar recht Ressourcensparend.
Fazit: Es gibt in meinen Augen keinen Grund gzip nicht zu verwenden..
EDIT: Wer an einem kleinen Benchmark interessiert ist, für den dürfte die folgende Seite interessant sein. Oder er führt einfach selbst Benchmarks durch (was bei ner Mietvm aber oft zu verfälschten Ergebnissen führt). https://www.rootusers.com/gzip-vs-bzip2-…nce-comparison/
Gzip wird bereits verwendet mit Level 6
Gzip wird bereits verwendet mit Level 6
Habe ich nicht überprüft.
War jediglich ein Kommentar auf Azey's Antwort
Freue mich schon auf die Eröffnung, wann auch immer sie stattfindet.
Hallo ihr Gürkchen!
Nach einer gewissen Zeit (ca. 2. Monate) melde ich mich auch wieder in diesem Thread.
Eventuell dachten viele, das Projekt sei beendet wurden(?) doch dem ist nicht so,
vor ca. 2 Monaten gab uns beiden (Tafelglotzer und mir) die Lust und Motivation an HabFiles
weiter zu arbeiten aus, aber nun bin ich wieder voll dabei um das Projekt weiterzuführen.
In der Mitte dies Projekts, hatten wir Probleme mit 2 unserer wichtigsten Funktionen
um die Möbelstücke "perfekt" zu rendern und originalgetreu wie im Client abbilden zu lassen,
doch jetzt da ich wieder Motivation und Lust habe, konnte ich einer der Probleme beseitigen.
Eigentlich steht dem Projekt so gut wie nichts mehr im Wege um Veröffentlich zu werden
und hoffentlich bleibt es auch erstmal dabei.
Ich bedanke mich bei euch für die zahlreiche Unterstützung die ich zum Projekt bekomme,
dabei hoffe ich natürlich auch, dass es sowas wie vor ca. 2 Monaten erstmal nicht passiert.
Mit freundlichen Grüßen
Sonay
Hört sich soweit gut an. Meine Frage ist dennoch ob es nur Möbel von Sulake geben wird oder auch Customs?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!