Developer PSA: labs.j-novel.club is your new friend!
-
@yanrishatum still, having the volume ID attached to the event would be helpful to me. As far as I can tell, it's just the event and series IDs, and the former is the ID of the event, not the part or volume.
That said, I can work around it by playing with the slugs.
-
@crimson-wise The reason there's no volume ID attached to that even is that we would actually have to figure out the volume of each event based on slug lookup, because it's not "attached" in the database, and that's inefficient to do right now, especially for large calendar queries
-
Added the following to the list:
GET https://labs.j-novel.club/app/v1/volumes/{ID or slug}/skus // Volume's third-party purchase options GET https://labs.j-novel.club/app/v1/volumes/{ID or slug}/price // Volume's pricing on JNC POST https://labs.j-novel.club/app/v1/me/credits/convert // Convert credits to coins POST https://labs.j-novel.club/app/v1/me/coins/purchase // Purchase coins POST https://labs.j-novel.club/app/v1/me/coins/redeem/{ID or slug} // Redeem coins by volume slug or ID GET https://labs.j-novel.club/app/v1/me/coins/options // Get coin pricing optionsAstute API users will notice that some more endpoints have been removed from the old API
-
Added GET https://labs.j-novel.club/app/v1/me/history. Required a
fromanduntilquery parameter with unix timestamps. Lowest acceptable value for either is1448841600 -
Is there any way to track when a manga volume was last updated or downloaded? For regular ebooks, /me/library has the lastDownload and lastUpdated fields, but I can't spot anything equivalent for manga.
-
It'd be great if the me/library's book.download object had a crc32 or any kind of hash. Even just the content length if nothing else; I tried HEADing the download link but there's no size in the headers even.
-
@talisein that's because the ebooks are generated on the fly as they're downloaded. Some sort of etag-equivalent unrelated to the content of the final ebook you download maybe be a possibility in the future, but it will probably never be a checksum of the content itself
-
Have to also note about /parts/$id/toc not making sense, as it clearly should be /series/$id/toc / /series/$id/parts
I know, it's weird. It's a quirk of dealing with the current database and how everything is connected, and it's just easier/more efficient for now to say "I am currently reading this part and I want the TOC for its series" for the mobile app, for which this API was originally designed for. We'll have a better TOC API in the future, probably /v2
Regarding your suggestion for accepted content-type, I'll look into it, first I have to make sure it doesn't break any of the clients
-
Added the following to the list:
PUT https://labs.j-novel.club/app/v1/me GET/POST https://labs.j-novel.club/app/v1/me/subscription POST https://labs.j-novel.club/app/v1/me/subscription/sync POST/DELETE https://labs.j-novel.club/app/v1/me/subscription/cancel POST https://labs.j-novel.club/app/v1/me/subscription/estimate GET/DELETE/PUT https://labs.j-novel.club/app/v1/me/method GET https://labs.j-novel.club/app/v1/me/method/setupSubscription management through the old API is no longer supported, and may be removed at any time.
P.S. I'm getting tired of updating/maintaining this list, it will soon be time for proper API docs, currently researching the most appropriate/best docs generator.
-
Thanks for making all this available, even unofficially -- if you add proper API docs that'll be more than some major companies provide for official partners. :)
Speaking of APIs ...
@chocolatkey said in Developer PSA: labs.j-novel.club is your new friend!:Knowing the kind of parameters each takes would be really helpful -- it's a lot harder to work backwards with protobufs!
-
@Ran Yeah protobufs docs is also part of what I want to expose... For now have this, you POST it a PurchaseRequest
message StripePaymentIntent { string payment_method = 1; string payment_intent = 2; } message PurchaseRequest { enum Processor { DEBUG = 0; // Only works when debug mode is enabled on the server STRIPE = 1; // Stripe // Insert app payment processors here! } Processor processor = 1; // The payment processor to use uint32 amount = 2; // The amount of coins to purchase oneof intent { // The payment intent from the processor StripePaymentIntent stripe_payment_intent = 3; } }If I remember correctly the enum values need to use the names in JSON, so "processor":"STRIPE"
-
@chocolatkey Awesome, thanks! That's exactly what I needed. You were totally right about the enum name -- and I would never have figured out how to pass along the payment intent without seeing the protos laid out like that.
-
Added a new
GET https://labs.j-novel.club/app/v1/series/{ID or slug}/aggregate, to get all data regarding a series (series, volumes, parts). Should be identical to making the individual requests -
Added "status" to series, which can be (in JSON format) one of "DEFAULT", "COMPLETE", "HIATUS"
-
Is it possible to get some pointers on the
/parts/$slug/dataendpoint? Light novel data is simple enough with/embed/$slug/data.xhtml, but doesn't work for manga. I am trying to get manga parts, but have no idea where to even start decoding the response. -
@Bartek The manga parts currently have DRM due to the stipulations of the original publisher(s). There is, therefore, no documentation on how to decode and display manga data
-
@chocolatkey Ah, too bad!
-
My question is regarding the covers. is there any reason, that the field originalUrl is always empty? i would need the cover in a higher resolution.
-
@TailsxKyuubi Because we don't actually have any original uploaded right now, it's planned for the future although I think that structure may change before then
-
@chocolatkey i dont understand the problem. they are already in some way uploaded. the ebooks itself already have the cover wouldnt it be possible to upload this in a automated process?
