You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 optionalquery field on the object which determines whether to do a normal fetch versus an actual search?
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.
The text was updated successfully, but these errors were encountered: