royalroad api

Une API non officielle pour royalroad.com.

 npm i -s @fsoc/royalroadl-api

C'est une tentative d'écrire un wrapper prévisible et cohérent autour du gâchis qui est RR. Étant donné qu'aucune API publique officielle n'est exposée, ce module arrête toutes les données directement du HTML, ce qui le rend très sujet à la mort spontanée et horrible.

La documentation Barebones générée à partir de Typedoc peut être trouvée sur FS-C.github.io/royalroad-api/. Vous pouvez également construire ces documents vous-même en exécutant npm run docs à la racine du projet.

Exemple d'utilisation

Pour plus d'exemples, consultez le répertoire /examples , voir également les tests dans /test .

 import { RoyalRoadAPI } from '@fsoc/royalroadl-api' ;

const api = new RoyalRoadAPI ( ) ;

const { data } = await api . fictions . getPopular ( ) ;
const titles = data . slice ( 10 ) . map ( ( fic ) => fic . title ) ;

console . log ( `The top 10 popular fictions are: ${ titles . join ( ', ' ) } ` ) ; 

À propos

Le module lui-même exporte uniquement une classe RoyalRoadAPI qui, en soi, n'a pas de méthodes. Toutes les fonctionnalités sont déléguées aux classes de services qui sont des propriétés de l'instance RoyalRoadAPI .

Réponses

Toutes les réponses et les erreurs sont soit un exemple de RoyalResponse , soit d'un RoyalError , qui étend RoyalResponse . Ceci est fait pour permettre facilement à la méta-information d'être clouée sur les réponses et à avoir une interface cohérente entre l'utilisateur et le module. Notez que le RoyalError agit de manière similaire à l'objet Error NodeJS, en ce qu'il capture et renvoie une trace de pile courte.

Par exemple, un appel à RoyalRoadAPI#fiction.getFiction() pourrait donner la réponse suivante sur le succès:

 RoyalResponse {
  data :
   { type : 'Original' ,
     tags : [ 'Action' , 'Adventure' , 'Sci-fi' , ... 3 more items ] ,
     stats :
      { pages : 766 ,
        ratings : 719 ,
        followers : 2991 ,
        favorites : 690 ,
        views : [ Object ] ,
        score : [ Object ] } ,
     title : 'Paladin' ,
     image :
      'https://www.royalroadcdn.com/(...)' ,
     status : 'HIATUS' ,
     author :
      { name : 'Komikhan' ,
        title : '' ,
        avatar :
         'https://www.royalroadcdn.com/(...)' ,
        id : 66486 } ,
     warnings : [ 'Gore' , 'Profanity' ] ,
     chapters : [ [ Object ] , [ Object ] , [ Object ] , ... 71 more items ] ,
     description :
      'When the first derelict alien spacecraft fell to Earth, (...)' } ,
  success : true ,
  timestamp : 1528119296799 }

... ou sur l'erreur:

 RoyalError {
  data :
   { message : 'Page Not Found' ,
     stack :
      [ 'Error' ,
        '    at new RoyalError' , ... 8 more items ] } ,
  success : false ,
  timestamp : 1528119381034 }

Demandeur interne

Toutes les classes de services utilisent la même instance du Requester , la classe responsable de la réalisation de demandes HTTP et du retour de leurs réponses. Par défaut, il lancera un RoyalError s'il rencontre un code d'état autre que 200 (cela peut être désactivé avec l'option ignoreStatus ).

Étant donné que RR aime en retourner 200 même lorsque la réponse réelle devrait être un 404 ou 304, le Requester analysera le HTML qu'il a obtenu (s'il en a obtenu), et essaiera de lire une erreur de celui-ci. S'il trouve des signes que la demande a échoué, il lancera - cela peut être désactivé avec l'option ignoreParser .

L'objectif principal du Requester est de garder une trace des cookies et de récupérer automatiquement un __ResponseVerificationToken souvent nécessaire pour les demandes de poste dans le cadre des mesures anti-CSRF. Cette récupération des jetons est désactivée par défaut et peut être activée avec l'option fetchToken .

Structure

Tous les services sont structurés de manière très similaire: avec un <Type>Service exposant toutes les méthodes pertinentes, et un <Type>Parser , qui expose généralement un certain nombre de méthodes statiques utilisées pour analyser les réponses HTML.

Une conclusion rapide de tous les services existants est:

• ChapterService , contient des méthodes pour récupérer et publier des chapitres et des commentaires de chapitre.
• FictionService , récupérer les données de fiction et les revues.
• FictionsService , Méthodes pour récupérer tous les types de listes de fiction offres RRL, avec leurs niveaux respectifs de détail par fiction.
• ProfileService , Gestion des profils, renvoie les profils utilisateur analysés.
• UserService , actions liées à l'utilisateur connecté comme la connexion, obtenant les fictions, les signets ou les notifications des utilisateurs.

Analyse

Cela utilise Cheerio pour analyser HTML, qui est un analyseur très indulgent. Cela signifie que même si RRL devait apporter des modifications mineures à leur disposition de pages, de grandes parties de l'API (même les parties responsables des zones modifiées) resteraient toujours fonctionnelles.

Par conséquent, attendez-vous à ce que les propriétés soient vides ou null , et sachez qu'une erreur ne sera pas jetée simplement parce que certaines valeurs ne pourraient pas être analysées.