feature request: Make GET channels/{target}/messages use request body instead of query parameters #15

New Issue

2026-02-16T12:28:58-05:00

yindo commented

2026-02-16 12:28:58 -05:00

Originally created by @QuantumToasted on GitHub (Nov 10, 2023).

What do you want to see?

At the moment, Search for Messages (POST channels/{target}/search) utilizes nearly identical parameters to Fetch Messages (GET channels/{target}/messages), but the former uses a JSON request body whereas the latter uses query parameters, which in my personal opinion is a worse way to build requests especially with as many parameters as the methods allow.

Would it be possible to make both endpoints use the same request body type (specifically a JSON request body instead of query parameters) for consistency? This would obviously be a breaking change for clients and API wrappers which depend on this functionality, but I think it would be better to get that over with sooner rather than later.

Originally created by @QuantumToasted on GitHub (Nov 10, 2023). ### What do you want to see? At the moment, [Search for Messages](https://developers.revolt.chat/api#tag/Messaging/operation/message_search_req) (`POST channels/{target}/search`) utilizes nearly identical parameters to [Fetch Messages](https://developers.revolt.chat/api#tag/Messaging/operation/message_query_req) (`GET channels/{target}/messages`), but the former uses a JSON request body whereas the latter uses query parameters, which in my personal opinion is a worse way to build requests especially with as many parameters as the methods allow. Would it be possible to make both endpoints use the same request body type (specifically a JSON request body instead of query parameters) for consistency? This would obviously be a breaking change for clients and API wrappers which depend on this functionality, but I think it would be better to get that over with sooner rather than later.

yindo added the enhancement label 2026-02-16 12:28:58 -05:00

yindo commented

2026-02-16 12:28:58 -05:00

@QuantumToasted commented on GitHub (Nov 10, 2023):

I've just remembered that the reason Fetch Messages uses query parameters is that GET methods cannot have a body, which is obviously something that has to be worked around and explains the usage of query parameters.

Might I instead propose a sort of "merging" of the two endpoints into one single Search for Messages endpoint with an optional query field on the object which determines whether to do a normal fetch versus an actual search?

@QuantumToasted commented on GitHub (Nov 10, 2023): I've just remembered that the reason Fetch Messages uses query parameters is that `GET` methods cannot have a body, which is obviously something that has to be worked around and explains the usage of query parameters. Might I instead propose a sort of "merging" of the two endpoints into one single Search for Messages endpoint with an **optional** `query` field on the object which determines whether to do a normal fetch versus an actual search?

yindo referenced this issue

2026-02-16 12:29:00 -05:00

[PR #15] [MERGED] fix(types/Core): change invite_only type to bool #26

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: stoatchat/javascript-client-api#15