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
Ripple resources are based on REST, so it should be fairly easy to enable serving them over HTTP. A request-response would simply be a strict subset of the realtime behaviour and just return a snapshot in time.
The HTTP request just needs to be translated to a request object (e.g. verb -> type, URL -> name, body -> value) and then passed to the existing resource handlers. The generic actions/mutations in use are (each of which can be an arbitrarily deep operation by specifying a key):
{ type: 'add', key: 'a.b.c', value }
{ type: 'update', key: 'a.b.c', value }
{ type: 'remove', key: 'a.b.c' }
Acceptable HTTP requests would be:
GET is a pull but without setting up a subscription.
PUT is an update at the root of the resource (i.e. with no key specified).
DELETE is a remove at the root of the resource (i.e. with no key specified).
POST/PATCH can just accept any change object as the body.
This would be useful for interoperability with existing tools like curl, or allowing developers to use fetch if desired.
Bonus: We can also auto-generate perfect hypermedia API with links by checking the media-type (e.g. application/hal+json) and returning the correct format with the link information.
The text was updated successfully, but these errors were encountered:
Ripple resources are based on REST, so it should be fairly easy to enable serving them over HTTP. A request-response would simply be a strict subset of the realtime behaviour and just return a snapshot in time.
The HTTP request just needs to be translated to a request object (e.g. verb ->
type
, URL ->name
, body ->value
) and then passed to the existing resource handlers. The generic actions/mutations in use are (each of which can be an arbitrarily deep operation by specifying a key):Acceptable HTTP requests would be:
GET
is apull
but without setting up a subscription.PUT
is anupdate
at the root of the resource (i.e. with no key specified).DELETE
is aremove
at the root of the resource (i.e. with no key specified).POST
/PATCH
can just accept any change object as the body.This would be useful for interoperability with existing tools like
curl
, or allowing developers to usefetch
if desired.Bonus: We can also auto-generate perfect hypermedia API with links by checking the media-type (e.g.
application/hal+json
) and returning the correct format with the link information.The text was updated successfully, but these errors were encountered: