NodeBB-ActivityPub Bridge Test Instance

@trwnh @AT1ST @oblomov the challenge is definitely much greater in a federated system.

In our case the caches aren’t the end all be-all and we have quite mature caching at multiple layers. The edge and end user caching is more a UX improvement (particularly for reducing latency) rather than to protect our servers. Expensive things should have their own backend caching and invalidation logic.

I see what you’re saying though.

@trwnh @AT1ST @oblomov For example, I might have GET /api/discussions which lists resources. I likely want to support a mechanism for that paginating, sorting, and filtering. For this I document query parameters for the purpose.

The resources themself will have a canonical URL generated by the server. In my case /discussions/3131/some-arbitrary-slug/p1

This time the pagination is encoded in the URL as well as arbitrary data.

@trwnh @AT1ST @oblomov there’s no fixed standards for bodies either though or paths. Data can be encoded in paths in arbitrary ways (including query parameters).

The client and server must agree on a serialization format in both cases. For bodies I typically use JSON. For paths the format is documented and generated by the application when possible.

@AT1ST @trwnh @oblomov this is true, however you can work around this by having the client code that generates URLs make them consistent. By and large end users are not typing URLs and certainly not query parameters.

@trwnh @AT1ST @oblomov well one massive negative to exposing your search as POST only is they your edge network can’t cache similar responses.

The query normalization doesn’t matter because the web app will ensure queries are in a consistent order.

As an example if you do /api/user/search?name=a* (such as in a mention lookup) then we can cache this response on our edge.

Now technically you could also cache a POST, but most edge networks can’t cache by body.

@trwnh @AT1ST @oblomov and how is it any more “right” to obscure the thing that was searched for in your logs, to the user, and when sharing links?

I definitely see the case for a search API endpoint (not exposed to the user) being a POST (and elastic search does this), but our user facing search page is definitely a GET. Modified filters and the query text end up as query parameters.

Just because full text search is suddenly involved why is GET no longer appropriate?