{"id":91048,"date":"2020-08-08T01:42:02","date_gmt":"2020-08-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy"},"modified":"2020-08-08T01:42:02","modified_gmt":"2020-08-07T23:42:02","slug":"ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"Il n'est pas recommand\u00e9 d'utiliser OFFSET et LIMIT dans les requ\u00eates de pagination","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Les jours o\u00f9 l'on pouvait ignorer l'optimisation des performances des bases de donn\u00e9es sont r\u00e9volus. Le temps ne s'arr\u00eate pas. Chaque nouvel entrepreneur du secteur technologique souhaite cr\u00e9er le prochain Facebook, cherchant \u00e0 collecter toutes les donn\u00e9es \u00e0 sa port\u00e9e. Ces donn\u00e9es sont n\u00e9cessaires aux entreprises pour former des mod\u00e8les de meilleure qualit\u00e9, qui aident \u00e0 g\u00e9n\u00e9rer des revenus. Dans de telles conditions, les programmeurs doivent cr\u00e9er des API qui permettent de travailler rapidement et efficacement avec d'\u00e9normes volumes d'informations.<\/p>\n

\"Il<\/a><\/noindex>
\n<\/a><\/noindex>
\nSi vous concevez des parties serveur d'applications ou des bases de donn\u00e9es depuis un certain temps, vous avez probablement \u00e9crit du code pour ex\u00e9cuter des requ\u00eates avec pagination. Par exemple, comme ceci :<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\nEst-ce bien le cas ?<\/p>\n
Mais si vous avez effectu\u00e9 la pagination de cette mani\u00e8re, je dois vous signaler avec regret que vous ne l'avez pas fait de mani\u00e8re tr\u00e8s efficace.<\/p>\n
Voulez-vous me contredire ? Vous pouvez<\/a><\/noindex> ne<\/a><\/noindex> perdre<\/a><\/noindex> du temps<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> et Mixmax<\/a><\/noindex> applique d\u00e9j\u00e0 des techniques que je souhaite vous pr\u00e9senter aujourd'hui.<\/p>\n
Nommez un d\u00e9veloppeur de backend qui n'a jamais utilis\u00e9 OFFSET<\/code> et LIMIT<\/code> pour ex\u00e9cuter des requ\u00eates avec pagination. Dans un MVP (produit minimum viable) et dans des projets o\u00f9 de petites quantit\u00e9s de donn\u00e9es sont utilis\u00e9es, cette approche est tout \u00e0 fait applicable. Elle fonctionne, pour ainsi dire, simplement.<\/p>\n
Mais si vous devez cr\u00e9er des syst\u00e8mes fiables et efficaces \u00e0 partir de z\u00e9ro, il est n\u00e9cessaire de se soucier de l'efficacit\u00e9 des requ\u00eates aux bases de donn\u00e9es utilis\u00e9es dans ces syst\u00e8mes.<\/p>\n
Aujourd'hui, nous allons parler des probl\u00e8mes li\u00e9s aux impl\u00e9mentations largement utilis\u00e9es (dommage que ce soit le cas) des m\u00e9canismes d'ex\u00e9cution des requ\u00eates avec pagination, et de la mani\u00e8re d'atteindre de hautes performances lors de l'ex\u00e9cution de telles requ\u00eates.<\/p>\n
Qu'est-ce qui ne va pas avec OFFSET et LIMIT ?<\/h2>\n
\nComme d\u00e9j\u00e0 mentionn\u00e9, OFFSET<\/code> et LIMIT<\/code> ils fonctionnent bien dans des projets o\u00f9 il n'est pas n\u00e9cessaire de traiter de gros volumes de donn\u00e9es.<\/p>\n
Le probl\u00e8me survient lorsque la base de donn\u00e9es s'agrandit au point de ne plus tenir en m\u00e9moire serveur. Cependant, il est n\u00e9cessaire d'utiliser des requ\u00eates avec pagination lors du travail avec cette base de donn\u00e9es.<\/p>\n
Pour que ce probl\u00e8me se manifeste, il faut qu'il y ait une situation o\u00f9 la SGBD recourt \u00e0 une op\u00e9ration inefficace de scan complet de la table (Full Table Scan) lors de l'ex\u00e9cution de chaque requ\u00eate avec pagination (pendant ce temps, des op\u00e9rations d'insertion et de suppression de donn\u00e9es peuvent se produire, et nous n'avons pas besoin des donn\u00e9es obsol\u00e8tes !).<\/p>\n
Qu'est-ce qu'un \"scan complet de table\" (ou \"scan s\u00e9quentiel de table\", Sequential Scan) ? C'est une op\u00e9ration au cours de laquelle la SGBD lit s\u00e9quentiellement chaque ligne de la table, c'est-\u00e0-dire les donn\u00e9es qu'elle contient, et v\u00e9rifie leur conformit\u00e9 \u00e0 la condition donn\u00e9e. On sait que ce type de scan de tables est le plus lent. En effet, lors de son ex\u00e9cution, il y a beaucoup d'op\u00e9rations d'entr\u00e9e\/sortie impliquant le syst\u00e8me de disque du serveur. La situation est aggrav\u00e9e par les temps d'attente li\u00e9s \u00e0 la manipulation des donn\u00e9es stock\u00e9es sur les disques, et le fait que le transfert de donn\u00e9es du disque vers la m\u00e9moire est une op\u00e9ration gourmande en ressources.<\/p>\n
Par exemple, vous avez des enregistrements sur 100000000 d'utilisateurs, et vous ex\u00e9cutez une requ\u00eate avec la structure OFFSET 50000000<\/code>. Cela signifie que la SGBD devra charger tous ces enregistrements (qui ne nous sont m\u00eame pas n\u00e9cessaires !), les placer en m\u00e9moire, et ensuite prendre, supposons, 20 r\u00e9sultats, comme mentionn\u00e9 dans LIMIT<\/code>.<\/p>\n
Disons que cela pourrait ressembler \u00e0 ceci : \"s\u00e9lectionner les lignes de 50000 \u00e0 50020 sur 100000\". Autrement dit, le syst\u00e8me pour ex\u00e9cuter la requ\u00eate devra d'abord charger 50000 lignes. Vous voyez combien de travail inutile il devra faire ?<\/p>\n
Si vous ne me croyez pas, regardez l'exemple que j'ai cr\u00e9\u00e9 en utilisant les capacit\u00e9s de db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"Il
\nExemple sur db-fiddle.com<\/i><\/p>\n
L\u00e0, \u00e0 gauche, dans le champ Sch\u00e9ma SQL<\/code>, il y a un code qui ins\u00e8re 100000 lignes dans la base de donn\u00e9es, et \u00e0 droite, dans le champ Requ\u00eate SQL<\/code>, deux requ\u00eates sont montr\u00e9es. La premi\u00e8re, lente, ressemble \u00e0 ceci :<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nEt la seconde, qui repr\u00e9sente une solution efficace au m\u00eame probl\u00e8me, est :<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nPour ex\u00e9cuter ces requ\u00eates, il suffit d'appuyer sur le bouton Ex\u00e9cution<\/code> en haut de la page. En faisant cela, nous comparerons les informations sur le temps d'ex\u00e9cution des requ\u00eates. Il s'av\u00e8re qu'une requ\u00eate inefficace n\u00e9cessite au minimum 30 fois plus de temps qu'une autre (d'un ex\u00e9cution \u00e0 l'autre, ce temps varie, par exemple, le syst\u00e8me peut indiquer que la premi\u00e8re requ\u00eate a pris 37 ms, alors que la seconde a pris 1 ms).<\/p>\n
Et si les donn\u00e9es augmentent, cela ne fera qu'empirer (pour vous en convaincre, regardez mon exemple<\/a><\/noindex> avec 10 millions de lignes).<\/p>\n
Ce que nous venons de discuter devrait vous donner une certaine compr\u00e9hension de la mani\u00e8re dont les requ\u00eates sont r\u00e9ellement trait\u00e9es dans les bases de donn\u00e9es.<\/p>\n
Gardez \u00e0 l'esprit que plus la valeur est \u00e9lev\u00e9e, OFFSET<\/code> plus le temps d'ex\u00e9cution de la requ\u00eate sera long.<\/p>\n
Que vaut-il mieux utiliser \u00e0 la place de la combinaison OFFSET et LIMIT?<\/h2>\n
\nAu lieu de la combinaison, OFFSET<\/code> et LIMIT<\/code> il vaut mieux utiliser une structure construite comme suit :<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nCeci est l'ex\u00e9cution d'une requ\u00eate pagin\u00e9e bas\u00e9e sur le curseur.<\/p>\n
Au lieu de stocker localement les courants OFFSET<\/code> et LIMIT<\/code> et de les transmettre avec chaque requ\u00eate, il faut conserver la derni\u00e8re cl\u00e9 primaire obtenue (g\u00e9n\u00e9ralement, c'est ID<\/code>Deep Speech LIMIT<\/code>, ce qui aboutira \u00e0 des requ\u00eates ressemblant \u00e0 celle ci-dessus.<\/p>\n
Pourquoi? La raison est que, en indiquant explicitement l'identifiant de la derni\u00e8re ligne lue, vous indiquez \u00e0 votre SGBD o\u00f9 commencer la recherche des donn\u00e9es n\u00e9cessaires. De plus, la recherche sera effectu\u00e9e efficacement gr\u00e2ce \u00e0 l'utilisation de la cl\u00e9, le syst\u00e8me n'aura pas \u00e0 se concentrer sur les lignes en dehors de la plage sp\u00e9cifi\u00e9e.<\/p>\n
Jetons un \u0153il \u00e0 la comparaison suivante des performances de diff\u00e9rentes requ\u00eates. Voici une requ\u00eate inefficace.<\/p>\n
\"Il
\nRequ\u00eate lente<\/i><\/p>\n
Et voici la version optimis\u00e9e de cette requ\u00eate.<\/p>\n
\"Il
\nRequ\u00eate rapide<\/i><\/p>\n
Les deux requ\u00eates renvoient exactement le m\u00eame volume de donn\u00e9es. Mais la premi\u00e8re prend 12,80 secondes, alors que la seconde ne prend que 0,01 seconde. Ressentez-vous la diff\u00e9rence?<\/p>\n
Probl\u00e8mes possibles<\/h2>\n
\nPour assurer le bon fonctionnement de la m\u00e9thode de requ\u00eate propos\u00e9e, il est n\u00e9cessaire que la table contienne une colonne (ou des colonnes) avec des index uniques et s\u00e9quentiels, tels qu'un identifiant num\u00e9rique. Dans certains cas sp\u00e9cifiques, cela peut d\u00e9terminer le succ\u00e8s de l'utilisation de telles requ\u00eates pour am\u00e9liorer la rapidit\u00e9 de l'acc\u00e8s \u00e0 la base de donn\u00e9es.<\/p>\n
\u00c9videmment, lors de la construction des requ\u00eates, il faut tenir compte des sp\u00e9cificit\u00e9s de l'architecture des tables et choisir les m\u00e9canismes qui fonctionneront le mieux avec les tables existantes. Par exemple, si vous devez traiter de grandes quantit\u00e9s de donn\u00e9es li\u00e9es dans les requ\u00eates, vous pourriez trouver cet article int\u00e9ressant. cette<\/a><\/noindex> article.<\/p>\n
Si nous faisons face \u00e0 l'absence de cl\u00e9 primaire, par exemple si nous avons une table avec une relation \u00ab plusieurs-\u00e0-plusieurs \u00bb, alors une approche traditionnelle impliquant l'utilisation OFFSET<\/code> et LIMIT<\/code>, nous conviendra certainement. Cependant, son utilisation peut entra\u00eener l'ex\u00e9cution de requ\u00eates potentiellement lentes. Dans de tels cas, je recommanderais d'utiliser une cl\u00e9 primaire avec auto-incr\u00e9ment, m\u00eame si elle est n\u00e9cessaire uniquement pour organiser l'ex\u00e9cution de requ\u00eates pagin\u00e9es.<\/p>\n
Si ce sujet vous int\u00e9resse \u2014 voici<\/a><\/noindex>, voici<\/a><\/noindex> et voici<\/a><\/noindex> \u2014 quelques ressources utiles.<\/p>\n
R\u00e9sultats<\/h2>\n
\nLa principale conclusion que nous pouvons tirer est que, quelle que soit la taille des bases de donn\u00e9es, il est toujours n\u00e9cessaire d'analyser la vitesse d'ex\u00e9cution des requ\u00eates. De nos jours, l'\u00e9volutivit\u00e9 des solutions est extr\u00eamement importante, et si, d\u00e8s le d\u00e9but du d\u00e9veloppement d'un syst\u00e8me, tout est bien con\u00e7u, cela peut \u00e0 l'avenir \u00e9viter \u00e0 un d\u00e9veloppeur de nombreux probl\u00e8mes.<\/p>\n
Comment analysez-vous et optimisez-vous les requ\u00eates aux bases de donn\u00e9es?<\/b><\/p>\n
\"Il<\/a><\/noindex>
\n
Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435. \u041a\u0430\u0436\u0434\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u0431\u0438\u0437\u043d\u0435\u0441\u043c\u0435\u043d \u0438\u0437 \u0441\u0444\u0435\u0440\u044b \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0445\u043e\u0447\u0435\u0442 \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0447\u0435\u0440\u0435\u0434\u043d\u043e\u0439 Facebook, \u0441\u0442\u0440\u0435\u043c\u044f\u0441\u044c \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c \u0432\u0441\u0435 \u0434\u0430\u043d\u043d\u044b\u0435, \u0434\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0442\u044f\u043d\u0443\u0442\u044c\u0441\u044f. \u042d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435 \u043d\u0443\u0436\u043d\u044b \u0431\u0438\u0437\u043d\u0435\u0441\u0443 \u0434\u043b\u044f \u0431\u043e\u043b\u0435\u0435 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u043e\u0434\u0435\u043b\u0435\u0439, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c. \u0412 \u0442\u0430\u043a\u0438\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91049,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00c9vitez d'utiliser OFFSET et LIMIT dans les requ\u00eates avec pagination | ProHoster","description":"Les jours o\u00f9 l'optimisation des performances des bases de donn\u00e9es n'\u00e9tait pas une pr\u00e9occupation sont r\u00e9volus. Le temps ne s'arr\u00eate pas.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f OFFSET \u0438 LIMIT \u0432 \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u0445 \u0441 \u0440\u0430\u0437\u0431\u0438\u0435\u043d\u0438\u0435\u043c \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u044b | ProHoster","og:description":"\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-07T23:42:02+00:00","article:modified_time":"2020-08-07T23:42:02+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91048","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:35:24","updated":"2026-08-11 12:50:11","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}