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

[ln-ws]

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

[ssddanbrown]

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.

[ln-ws]

The proposed benefits are actual benefits. Do you disagree?

[ln-ws]

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]

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.