Repository navigation
Paginate Message APIs #34
Description
Adjust APIs:
GET /application/{id}/messageGET /message
New Query Parameter:
limit=uintthe amount of messages to returnsince=datereturn all messages before this date (limited by limit)since=idreturn all messages before the given message id
Expected Response:
{
"paging": {
"limit": 50,
"next": "https://requesturl.com/message?limit=from-request&since=message-id"
},
"data": [
{"id":12183,"appid":1,"message":"mymsg","title":"mytitle","priority":0,"date":"2018-03-20T19:30:51.596354+01:00"}
]
}
Activity
lslah commentedon Mar 24, 2018
since=idis probably better as two messages might have the same date, see https://coderwall.com/p/lkcaag/pagination-you-re-probably-doing-it-wrongjmattheis commentedon Mar 24, 2018
@lslah Using ids for pagination seems to be better. Good point!
[#34] Adjust message api to be paged
[#34] Add db calls for paged message api
[#34] Add error messages for min and max
[#34] Update update api documentation & Increase api version
[#34] Add react-list UI dependency
[#34] Adjust action to adjusted api
[#34] Add react-list & lazy-loading to Messages & Adjust store to mak…
[#34] Add delete messages action handling
[#34] Add key to react list
[#34] Adjust message api to be paged
[#34] Add db calls for paged message api
[#34] Add error messages for min and max
[#34] Update update api documentation & Increase api version
[#34] Add react-list UI dependency
[#34] Adjust action to adjusted api
[#34] Add react-list & lazy-loading to Messages & Adjust store to mak…
[#34] Add delete messages action handling
[#34] Add key to react list
naimo commentedon Jun 15, 2020
The name of the parameter seems weird to me : message ids get incremented, so the message received by the server "since" a given id are those with higher numbers.
Keeping the current behavior, the parameter should be renamed "until" or "before". Better though would be to keep "since" but actually return new messages. Seems to be a more frequent use case no ?
jmattheis commentedon Jun 15, 2020
@naimo Naming is hard (:.
I think, I called it this way because the messages are sorted in descending order. Thus,
sincekinda makes sense. The behavior is also documentedI don't think this renaming would justify a breaking API change.
It is actually not because new messages will be transmitted via web socket. Still, the API addition would have some use cases.
naimo commentedon Jun 15, 2020
jmattheis commentedon Jun 15, 2020
@naimo Yeah, our android app does something similar. I've created #329 to add this functionality.