Next page token presence does not behave as documented

[radiozradioz]

Describe the bug

The documentation says this:

| nextPageToken | string | A token, which can be sent as page_token to retrieve the next page. If this field is omitted, there are no subsequent pages. | No |

When I make a ListMemos request that will have no next page, e.g. curl https://memos.example.com/api/v2/memos?pageSize=50&filter=row_status%20%3D%3D%20'NORMAL' , the returned page token is an empty string rather than being absent:

{..."resources":[], "relations":[], "reactions":[]}], "nextPageToken":""}

The documentation implies that the field will be absent. This is incongruent.

Personally I think the fix should either be ommitting the field or setting it to null when there is no extra page. Empty string is not an acceptable stand-in for null.

Steps to reproduce

Run a ListMemos query with a page size that is higher than the number of memos in your instance.

The version of Memos you're using

v0.24.1

Screenshots or additional context

No response

[radiozradioz]

In usememos/memos#4514 , commenters noted that the field should not be optional according to Google's AIP. The PR was then closed under the assumption that the nullability field was irrelevant. I see that this issue has been moved to usememos/dotcom, implying that the intended fix for this situation is to change the documentation.

Personally I think discussing the nullability of the field is relevant. Indeed the documentation should be updated, but I also think the current behavior of the API is undesirable. I think that an empty string is not a good substitute/representation for null, and that the API should be updated to return null here instead of an empty string.

Unless it's an express "no" for changing the field behavior, I suggest we put the issue back into usememos/memos because it encompasses a functional change to the server, not just a change to the documentation.

Here is my comment in the PR with my reasoning: usememos/memos#4514 (comment)