Want API that read the contents of item

⚙Developers
#1

If I want the contents of one item , I can use POST https://dynalist.io/api/v1/doc/read.
However, this API is very wasteful because it retrieves the entire contents of the document.

Therefore, I want you to be able to specify the items to be acquired.
For example:
Add item_ids parameter to the request parameters of POST https://dynalist.io/api/v1/doc/read
The item_ids is Array(String) . The IDs of the items to fetch.

#2

Hmm may I ask what is your use-case for this endpoint?

#3

For example when write life logs under date item.
If there is “2020-03-20”, write below it.
If there is no “2020-03-20”, create “2020-03-20” and write below it.

  ・2020-03-19
    ・ log A
    ・ log B
  ・2020-03-20
    ・ log C

First get children ids of parent item.
Next get content of children.
Check if content of the item is “2020-03-20”.

#4

So in your use-case, you’ll be making a request on the parent item for getting children list, then another request to get the contents of each child? Seems to me that the current API endpoint should work just fine and you’ll get a lot less latency (at the cost of extra bandwidth, which should be gzipped). Is bandwidth your primary concern?

I would argue that

  1. Generally it costs more computation (from our standpoint) for multiple requests than spending a bit more bandwidth for the full reply (which is usually compressed anyway).
  2. It would reduce latency on your end for your script or app, at the cost of bandwidth.
  3. It makes the API more bloated to add a new endpoint (or having multiple behaviors under the same endpoint) for something that can already be done with the current set.

However, to me it also sounds like a useful addition for some specific use cases:

  1. In the future if we have a way to notify what items changed since last time you fetched, it would be beneficial to have an endpoint that only returns partial information of the document.
  2. If there’s a way to make a single request it does save bandwidth, especially for mobile application use.
#5

I envision using it on mobile.

For small documents, the current API is sufficient.
But the larger the document, the greater the benefit of getting one item.
Such as a life log or diary is what increases forever.

I do not think it is necessary soon, because it’s not impossible with the current API.
I believe it will be useful in the future.