2 ms·
I don't feel especially strongly about the PUT vs PATCH distinction. But I left a comment on the thread you linked: I'm just not convinced there's a need for 20
by bastawhiz 2y ago
I don't feel especially strongly about the PUT vs PATCH distinction. But I left a comment on the thread you linked: I'm just not convinced there's a need for 209. Braid is trying to be both application logic and a transport protocol, but it doesn't have to be. SSE isn't perfect but all of the concerns around it could be addressed with relatively simple solutions.
- toomim 2y agoI'm not convinced on 209, either. There might be a better response code. See the discussion at https://github.com/braid-org/braid-spec/issues/16 https://github.com/braid-org/braid-spec/issues/16 Braid is not trying to be "application logic" or "transport protocol" -- it is a State Synchronization Protocol. If you can think of a more elegant method to support all of state synchronization within SSE, we're all ears! But AFAICS you end up having to embed base64-encoded HTTP responses within SSE events within HTTP responses, which is gross pile of russian dolls, where both the innermost and outermost dolls are the same type of doll -- an HTTP response! So why all the intermediate dolls? It's more elegant and simpler to extend HTTP at the root level, and say: "Instead of returning 1 HTTP response, a Braid server can return N HTTP responses, concatenated together with optional newline separators."