Enhance /pages/{id} and /chapters/{id} READ responses with additional book and chapter information #4934

Open
opened 2026-02-05 09:27:20 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @ln-ws on GitHub (Aug 27, 2024).

Describe the feature you'd like

We propose enhancing the response data for READ requests on the /pages/{id} and /chapters/{id} endpoints to include additional contextual information:

For /pages/{id}:

Add book_name
Add book_slug
Add chapter_name
Add chapter_slug

For /chapters/{id}:

Add book_name
Retain existing book_slug

This enhancement would provide a more comprehensive response, allowing API consumers to access hierarchical information about a page or chapter in a single request.

Describe the benefits this would bring to existing BookStack users

  • Reduced overhead on the network, server and client device, as there is no need to explicitely query for the data with another read request to the corresponding /books/{id} or /chapters/{id} endpoint
  • More straight forward code and data requests for the API users

Can the goal of this request already be achieved via other means?

Currently you'd have to send another READ request to either the /books/{id} or /chapters/{id} endpoint to fetch the required information.

Have you searched for an existing open/closed issue?

  • I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

3 months to 1 year

Additional context

No response

Originally created by @ln-ws on GitHub (Aug 27, 2024). ### Describe the feature you'd like We propose enhancing the response data for `READ` requests on the `/pages/{id}` and `/chapters/{id}` endpoints to include additional contextual information: For `/pages/{id}`: Add `book_name` Add `book_slug` Add `chapter_name` Add `chapter_slug` For `/chapters/{id}`: Add `book_name` Retain existing `book_slug` This enhancement would provide a more comprehensive response, allowing API consumers to access hierarchical information about a page or chapter in a single request. ### Describe the benefits this would bring to existing BookStack users - Reduced overhead on the network, server and client device, as there is no need to explicitely query for the data with another read request to the corresponding `/books/{id}` or `/chapters/{id}` endpoint - More straight forward code and data requests for the API users ### Can the goal of this request already be achieved via other means? Currently you'd have to send another `READ` request to either the `/books/{id}` or `/chapters/{id}` endpoint to fetch the required information. ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundamental request ### How long have you been using BookStack? 3 months to 1 year ### Additional context _No response_
OVERLORD added the 🔨 Feature Request🔩 API Request labels 2026-02-05 09:27:20 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Aug 27, 2024):

Thanks for the request @ln-ws, but between this request and your others, I'm fairly confident an LLM is in use here. Please avoid using any kind of AI/LLM directly when creating issues here.
I don't want to spend my own time, or have others waste their time, attempting to understand overly verbose machine generated text.

Any indication of actual benefits is lost in the mass of text which list generic benefits that could be used to justify any additional data being added to endpoints.

@ssddanbrown commented on GitHub (Aug 27, 2024): Thanks for the request @ln-ws, but between this request and your others, I'm fairly confident an LLM is in use here. Please avoid using any kind of AI/LLM directly when creating issues here. I don't want to spend my own time, or have others waste their time, attempting to understand overly verbose machine generated text. Any indication of actual benefits is lost in the mass of text which list generic benefits that could be used to justify any additional data being added to endpoints.
Author
Owner

@ln-ws commented on GitHub (Aug 27, 2024):

The proposed benefits are actual benefits. Do you disagree?

@ln-ws commented on GitHub (Aug 27, 2024): The proposed benefits are actual benefits. Do you disagree?
Author
Owner

@ln-ws commented on GitHub (Aug 27, 2024):

Sorry if I made you feel like you're wasting your time. But I don't see any reason to write a feature request without giving you my arguments for that very feature. That would make the feature request kind of... pointless wouldn't it?

@ln-ws commented on GitHub (Aug 27, 2024): Sorry if I made you feel like you're wasting your time. But I don't see any reason to write a feature request without giving you my arguments for that very feature. That would make the feature request kind of... pointless wouldn't it?
Author
Owner

@ln-ws commented on GitHub (Aug 27, 2024):

I have now reduced my feature request to the bear minimum for any developers that want to save 147 seconds while reading the proposal for a new feature. IMHO the quantity of time is not worth the quality of arguments, but that is also off the topic for this discussion.

@ln-ws commented on GitHub (Aug 27, 2024): I have now reduced my feature request to the bear minimum for any developers that want to save 147 seconds while reading the proposal for a new feature. IMHO the quantity of time is not worth the quality of arguments, but that is also off the topic for this discussion.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#4934