Messages in past n days endpoint

[wookie184]

A GET endpoint that takes data from the body is a bit dodgy which made this a pain 😩 . Am open to any improvements, I considered using a POST but not sure it's worth changing at this point.

Closes #783

[netlify]

✅ Deploy Preview for pydis-static ready!

Name	Link
🔨 Latest commit	7b49952
🔍 Latest deploy log	https://app.netlify.com/sites/pydis-static/deploys/637a2d683246740008371e9b
😎 Deploy Preview	https://deploy-preview-789--pydis-static.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[coveralls]

Coverage remained the same at 100.0% when pulling 7b49952 on messages-in-past-n-days-endpoint into 42feef2 on main.

[jchristgit]

This was still being worked out re: conversation in #dev-core, right?

[wookie184]

Yeah, I think I'll just change it to be a POST endpoint.

[wookie184]

Should be ready for review now

[wookie184]

Thoughts on changing this to return 0 for users with no messages?

I didn't do it originally because it would also return 0 for invalid IDs which could potentially be misleading, but now i'm thinking it would probably be more useful if it just returned 0 for the ID if nothing was found.

[shtlrs]

I guess we could have the user ids as comma-separated-values, but we'd be running the risk of having too long query strings :/
I think it's fine to have this as a POST endpoint, even though it "sounds" wrong.

The only way to make this a GET would be to fetch the data of one user, but it would basically be a waste of bandwidth.

I'm saying this because I don't know what was discussed in #dev-core, so just shooting out ideas.

[shtlrs]

Thoughts on changing this to return 0 for users with no messages?

I didn't do it originally because it would also return 0 for invalid IDs which could potentially be misleading, but now I'm thinking it would probably be more useful if it just returned 0 for the ID if nothing was found.

I think it would be a good idea to return 0 for users with no messages.

Currently, if at least one id is invalid, the request won't be successful and will return with the encountered errors.

Unless there's a detail that I'm missing

[wookie184]

I was referring to the case where we can't tell if the ID is correct or not. For cases where it's not an integer or is negative the API user has clearly done something wrong so I think it makes sense to return an error response.

The issue is that with the current query we can't tell between users with no messages in that period and users that don't exist (but with the ID in the correct form). I think i'll change it so that does return 0 anyway though, as it's probably more useful.

[shtlrs]

I was referring to the case where we can't tell if the ID is correct or not. For cases where it's not an integer or is negative the API user has clearly done something wrong so I think it makes sense to return an error response.

The issue is that with the current query we can't tell between users with no messages in that period and users that don't exist (but with the ID in the correct form). I think i'll change it so that does return 0 anyway though, as it's probably more useful.

When would we have the case of a non existent ID ?
Because what I'm wondering is, if the user is a member of server but not found in the database, we would have a delta between the number of items returned by the server & the number of items requested.

And if the user is not in the database, then the query won't return any information about them since they don't exist.

What I'm thinking is, if we "desperately" want that information, we can have some sort of query post-processing before the API returns a response, and non existent user will have a value of -1 for example.

[wookie184]

This is ready for review now.

What I'm thinking is, if we "desperately" want that information, we can have some sort of query post-processing before the API returns a response, and non existent user will have a value of -1 for example.

We don't need that information currently, so it's probably not worth overcomplicating it.

[jchristgit]

Legend man. LEGEND.

[jchristgit]

This is what the American country has been looking forward to for years. As a single nation, we are finally able to provide a detailed and in-depth aggregation of information on American citizens, which further improves our commitment to a brighter future for our citizens. It is imperative to be aware of our environmental impact, and I am hereby signing this pull request into master.

[Xithrius]

I see no issues with the current implementation of this feature.