Developer PSA: labs.j-novel.club is your new friend!

chocolatkey

@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

chocolatkey

@yanrishatum

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

chocolatkey

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/setup

Subscription 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.

Ran

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!:

POST https://labs.j-novel.club/app/v1/me/coins/purchase

Knowing the kind of parameters each takes would be really helpful -- it's a lot harder to work backwards with protobufs!

chocolatkey

@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"

Ran

@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.