Given this REST API response for a cursor-based pagination request, what is the value of next_cursor?
{
"data": ["item21", "item22", "item23"],
"next_cursor": "MjQ=",
"has_more": true
}Look for the field that represents the cursor for the next page.
The next_cursor field contains the encoded cursor string to fetch the next page. Here it is "MjQ=".
Which of the following is the main advantage of cursor-based pagination over offset-based pagination?
Think about what happens if new items are added or removed while paginating.
Cursor-based pagination uses a stable cursor to continue from the last item, preventing skipping or duplication when data changes. Offset-based pagination can miss or repeat items if the dataset changes.
What error will this API response cause when used for cursor-based pagination?
{
"data": ["item10", "item11"],
"next_cursor": null,
"has_more": true
}Check if the cursor and has_more fields agree on whether more data exists.
If has_more is true, there should be a valid next_cursor to continue pagination. Null cursor with has_more true is inconsistent and will cause errors.
Choose the correct JSON snippet that encodes the cursor as a base64 string for the next page.
Remember JSON strings must use double quotes and no function calls inside JSON.
Option D correctly uses a base64 encoded string in double quotes. Option D is invalid JSON with a function call. Option D uses Python bytes syntax, invalid in JSON. Option D uses single quotes, invalid in JSON.
An API returns 3 items per page. The dataset has 7 items total. After fetching two pages using cursor-based pagination, how many unique items have been retrieved?
Calculate items per page times pages fetched, but consider total items available.
Each page returns 3 items. Two pages return 6 items total. Since dataset has 7 items, 6 unique items are retrieved after two pages.