royalroad api

Royalroad.com的非官方API。

 npm i -s @fsoc/royalroadl-api

这是试图在RR的混乱中编写可预测且一致的包装器。由于没有官方的公共API暴露，因此该模块直接从HTML中刮掉了所有数据，这使其非常容易自发而可怕的死亡。

可以在fs-c.github.io/royalroad-api/上找到从键入oc产生的准则文档。您还可以通过在项目的根源中运行npm run docs来自己构建这些文档。

示例用法

有关更多示例，请查看/examples目录，另请参见/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 ( ', ' ) } ` ) ; 

关于

该模块本身仅导出一个RoyalRoadAPI级别，该类本身没有方法。所有功能均委派给了RoyalRoadAPI实例的属性的服务类。

回答

所有回应和错误都是RoyalResponse的一个实例，或者是RoyalError的实例，它扩展了RoyalResponse 。这样做是为了轻松地允许将元信息传输到响应中，并在用户和模块之间具有一致的接口。请注意， RoyalError作用类似于NodeJS Error对象，因为它捕获并返回一个简短的堆栈跟踪。

例如，对RoyalRoadAPI#fiction.getFiction()的呼吁可能会产生以下关于成功的回应：

 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 }

...或错误：

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

内部请求者

所有服务类都使用Requester的相同实例，该类负责提出HTTP请求并返回其响应。默认情况下，如果它遇到其他200以外的状态代码，它将抛出一个RoyalError （可以使用ignoreStatus选项禁用）。

由于RR也喜欢返回200，即使实际响应应为404或304， Requester将解析其获得的HTML（如果有的话），并尝试从中读取错误。如果发现该请求失败的迹象，它将投掷 - 可以使用ignoreParser选项禁用。

Requester的主要目标是跟踪cookie，并自动获取通常需要作为post请求作为反CSRF措施的一部分所需的__ResponseVerificationToken 。默认情况下禁用了令牌的这种获取，可以使用fetchToken选项启用。

结构

所有服务都是以非常相似的方式结构的： <Type>Service揭示所有相关方法，而<Type>Parser通常会暴露出许多用于解析HTML响应的静态方法。

快速总结所有现有服务是：

• ChapterService包含获取和发布章节以及章节评论的方法。
• FictionService ，获取虚构数据和评论。
• FictionsService ，获取所有类型的虚构列表RRL提供的方法，其每个小说细节的水平各自。
• ProfileService ，处理配置文件，返回解析的用户配置文件。
• UserService ，与登录用户有关的操作，例如登录，获取用户的虚构，书签或通知。

解析

这使用Cheerio来解析HTML，这是一个非常宽容的解析器。这意味着，即使RRL要对其页面布局进行次要更改，API的大部分（即使是负责更改区域的零件）仍然可以保持功能。

因此，期望属性是空的或null ，并且知道仅仅因为无法解析某些值而不会丢弃错误。