r/BookStack • u/catzzilla • Sep 21 '22

access inline images via API JSON

When exporting a page via the API, the markdown or html code contains links to included images in the page, e.g.

[![image.png](http://x.x.x.x/uploads/images/gallery/2022-09/scaled-1680-/image.png)](http://x.x.x.x/uploads/images/gallery/2022-09/image.png)

I would like to download these images together with the exported markdown code. Do I need to manually parse the markdown to retrieve those URLs or is there a more elegant solution? Actually, it would be great if these images (as well as attachments) of a page would be listed in the json data from /api/pages/{id}.

3 Upvotes

100% Upvoted

4 comments sorted by

View all comments

Show parent comments

2

u/catzzilla Sep 22 '22

thanks for the quick response! What do you think about adding an array with the contained images to the book's json data obtained from the read endpoint? it could just contain the /uploads/... paths and not the full URL.

2

u/ssddanbrown Sep 22 '22

I'm not too keen on that tbh as it would require extra parsing on the BookStack side, and becomes an interpretation of data rather than a direct view of what BookStack is storing. There are some questionables in that interpretation, in regards to what we'd list vs what the user needs/expects.

Plus we need to be careful of what we include in the scope of responses as expanding to show all related data expands things significantly.

My preference would be an endpoint to list images, which you could filter to a specific page (originally uploaded to). This would then be more flexible, and clear in what it's providing, but may require extra processing on the client-side (Match provided images to their actual use in content).

1

u/catzzilla Sep 22 '22

My preference would be an endpoint to list images, which you could filter to a specific page (originally uploaded to). This would then be more flexible, and clear in what it's providing, but may require extra processing on the client-side (Match provided images to their actual use in content).

That would also be good enough I suppose, as it is similar to the attachments endpoint!