Arrêtons les bêtises

vous deuhez les gros geek on comprend rien arrêtez de baver sur votre clavier svp, vous nous rendrez service

de base on était ici pour jouer au jeu du celib et sauter dans la piscine, qu'est-ce qu'on est devenu sérieux à parler d'api et de jsp quoi... on dirait des accros à league of legends

les termes

Les termes jusqu'à ce qu'une flopée de joueurs se plaignent de ne plus pouvoir accéder à l'hôtel, et qu'on leur répondra "videz votre cache"....

@gogolafarce - Ton argumentaire est pas mauvais, dans le cadre d'un projet correctement architecturé, avec des traitements back-end moderne. Ce n'est pas le cas sur HabboCity, et ce que je dénonce est déjà arrivé des dizaines de fois, justement à cause de ce genre de fonctionnalité, qui, concrètement ne servent à rien mise à part donner à manger à celles et ceux qui jouent à faire tomber l'hôtel.

@irone va prendre l'air

@Irone Déjà de base, on va pas se mentir que l'API de City n'a pas vraiment d'utilité, normalement une API permet aux développeurs externes de récupérer des données controlées, mais elle permet aussi aux développeurs internes d'utiliser ses endpoints dans leurs codes afin d'éviter la répétition de code, bêtement pour un site, on va utiliser un endpoint "/v1/player/{userId}/groups" pour affichier les groupes du joueur au lieu de faire un "SELECT * FROM groups WHERE userid = ?" dans chaque page qui néccesite ce code.
Je ne suis pas sûr que le code d'HabboCity soit basé sur ce principe, donc l'utilité de l'API initial est 0.

Perso j'utilise mon API dans énormément de codes et ça évite que chaque site soit connecté à la base de donnée.
Bêtement mon bot Discord récupère les informations uniquement via mon API vu qu'il s'agit simplement d'un "data display", pareil pour le panel admin, il récupère uniquement les données via l'API, et lorsqu'il doit faire des POST, pareil, il gère cela par l'API.
Après chaque endpoint est sécurisé par un token, suivant ton token, tu n'as pas accès à tous les endpoints, bêtement un joueur qui veut créer un bot pour voir les statistiques de sa guilde aura uniquement aux endpoints selectionnés sur le dev panel.

Puis franchement je pense que l'API est totalement à refaire, passer sur une structure REST avec un versioning serait déjà la base, ensuite mettre en place des tokens en header, mais bon, j'imagine que @Salius a prévu cela.
N'est-ce pas Salius ? 🤡

@Equitable comme annoncé, une série de majs pr l'api est prévu dont oui la reconstruire

@Irone oui bon après si les développeurs ont appris à coder sur youtube aussi... si y'a un /api/users avec zéro pagination et qu'en plus cette route ne sert à rien faut changer de développeur, c'est vraiment le minimum quand tu codes en prod sérieux

@-Moha jsp pk tu nous fais le mec ici gros t'es un pixel comme tous l'monde qui joue à habbocity si tu comprends pas un sujet commente pas et vas sur les sujets que tu comprends genre jsp les trucs faciles à comprendre

@gogolafarce Mdr mais je pense que t'as pas conscience, city est fait avec une architecture server-driven hyper basique : chaque action est traitée par un script PHP dédié et le javascript navigue vers ces URLs en modifiant window.location ou via des formulaires soumis dynamiquement.......... et l'api est un projet dédié, non relié aux logiques métier qui sert à exposer les datas de la même bdd. Le CMS c'est une approche monolithique sans API

@DANCEWITHMEEE c'est quoi gearth??

@Irone bah pour le site tu peux faire une API REST avec Spring ou quoi et lâcher cette merde en vrai

@gogolafarce C'est ce que j'aimerai prôner, mais ça ne semble pas être partagé par l'équipe de développement... C'est clairement et de très loin la meilleure trajectoire pour City, et j'aurai aimé que cette V3 puisse prendre cette direction pour capitaliser sur les efforts fournit. (Bon pas en Spring, full typescript par contre ^^')

@Irone ouais Spring ou typescript après ça dépends, le projet est en java donc conversion des classes java actuelles en entités puis routes spring c'est pas à exclure je pense