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 ，並且知道僅僅因為無法解析某些值而不會丟棄錯誤。