Introspected REST: An alternative to REST and GraphQL

Re:Introspected REST: An alternative to REST and GraphQL by lucideer on Saturday December 22, 2018 @08:16AM (#18740444)

You seem to be describing a use-case for HTTP PATCH.

What is there about what you're describing that's more difficult with PATCH than alternative protocols?

Unless of course you have two users directly editing the same field simultaneously, but this is a direct conflict case that any underlying implementations will have to have their own strategy for—HTTP wouldn't be any different to anything else here.

[ Parent | on HN ]

Re:Introspected REST: An alternative to REST and GraphQL by jondubois on Saturday December 22, 2018 @09:03AM (#18740600)

That's true, PATCH would solve that specific writing aspect of the problem, but there is still the issue that each user would not know that the other user has changed another property; we need some kind of server push mechanism to inform users that the underlying data has changed. Also, if users update one field at a time, it's more expensive to have one HTTP request per field (considering the HTTP headers overhead and potentially having to open a new connection) rather than using one WebSocket frame per update.

[ Parent | on HN ]

Re:Introspected REST: An alternative to REST and GraphQL by icebraining on Saturday December 22, 2018 @11:42AM (#18741252)

there is still the issue that each user would not know that the other user has changed another property; we need some kind of server push mechanism to inform users that the underlying data has changed

If the data occasionally changes, you can just respond to the update request with a 409 Conflict reporting the problem and allowing the user to fix it. If it's changing so fast that it requires real-time updates, the user can't probably keep up either, so you should re-think your mechanism.

[ Parent | on HN ]

Re:Introspected REST: An alternative to REST and GraphQL by jungturk on Saturday December 22, 2018 @10:33AM (#18740948)

Server-sent events might be a good fit here.

Note that SSE belongs to the content layer (HTML) rather than the transfer layer (HTTP) so its specifically about notifications to active clients about content changes to resources they're observing.

Here's someone describing their experience with it: https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c...

[ Parent | on HN ]

Re:Introspected REST: An alternative to REST and GraphQL by jondubois on Saturday December 22, 2018 @05:16PM (#18742798)

The fact that the SSE connection is unidirectional makes it impossible to quickly and efficiently detect disconnection from the server-side; this costs extra in terms of performance.

Also, SSEs make it essentially impossible to implement features like real-time user online/offline presence and automatic renewal of authentication tokens (without closing the previous real-time/SSE connection).

[ Parent | on HN ]

Re:Introspected REST: An alternative to REST and GraphQL by jungturk on Wednesday December 26, 2018 @11:03AM (#18762756)

Good points about the limitations - SSE certainly won't be useful for lots of scenarios and you might prefer resorting to traditional approaches in those scenarios (in lieu of or in concert with an SSE channel).

[ Parent | on HN ]