8 ms·

1. Why not a SUB HTTP request? And a PUB http request. The response URL could be a required header. 2. We have HEAD, can we do service discovery using HEAD? 3

1. Why not a SUB HTTP request? And a PUB http request. The response URL could be a required header. 2. We have HEAD, can we do service discovery using HEAD? 3. Why not let a topic be a HTTP URL? “PUB /user/john/position HTTP/1.1\r\ndata...”. 4. Subscription expiration as a way to force subscribers to renew and upon renew get redirected to other servers is pretty cool. NATS has a special message (the INFO message) to do the same, but you might be in the middle of an important request-reply session you don’t want to abort. 5. The authors could have made this protocol very “non-http-ish” by implementing what amounts to Redis but in HTTP. I’m glad they didn’t. This still feels like HTTP, which is great.

voltagex_ 8y ago
Middleboxes and bad HTTP servers/clients would explode, I guarantee it.
- friend-monoid 8y ago
  But we have the PATCH method, which is... Non-standard, I think? And it works fine.
  - icebraining 8y ago
    It's been a standard for a few years: https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789
- lomnakkus 8y ago
  Always use HTTPS?
treve 8y ago
I don't think we need more HTTP methods, unless a real case can be made for the existing ones not being good enough. The HTTP strongly discourages it. But I love the idea of topics being Uris (not just HTTP)
jcrites 8y ago
"topics" are indeed HTTP URLs: 1. Definitions Topic. An HTTP (or HTTPS) resource URL. However, you subscribe to a topic by interacting with a different "hub" URL, passing the "topic" URL as a parameter (`hub.topic`). Service discovery does appear to support HEAD requests. (See section 4.) Having a new HTTP verb for subscribing and publishing would seem like unnecessary complexity to me. Rather than ask "why not a new verb", I think a case would need to be made that a new verb is required, that the operation does not cleanly fit into the semantics of existing verbs. The existing verbs are capable of modeling quite a lot. With the protocol as they've described it, subscribing is just sending an HTTP POST to the hub URL, passing in the topic URL. That's a simple HTTP operation that a lot of clients and programs can be instructed to do easily. Requiring the use of a new HTTP verb will make interoperability difficult without apparent benefit.
- dnomad 8y ago
  > Having a new HTTP verb for subscribing and publishing would seem like unnecessary complexity to me. Complexity for who? Introducing a secondary "hub" resource here is just accidental complexity. If I want to subscribe to resource A why am I talking to a different resource B? And once you introduce a secondary resource now you need yet another service discovery mechanism to support discovery of these pseudo-resource hubs. (Heaven forbid using an existing service discovery mechanism like RDDL.) Honestly stuff like this is just so poorly thought out it's difficult to understand why W3C stamps approval on this crap. There's no consideration given to alternate protocols like WebSockets or XMPP and there's no attempt to layer on top of existing standards in a meaningful way (hub.secret -- really???). Worst of all there's no real understanding here of what it means for a resource to change. The entire Content-Distribution model is geared towards just one very narrow use case. It's clear the W3C is all about being "inclusive" and "moving fast" there's real fear of "overthinking" things -- but seriously if this is the result we'd probably better off with better standards once a decade then this.
  - pjc50 8y ago
    New HTTP verbs require support in the web server, and all proxies along the way, while using existing ones doesn't and is just part of the normal application framework.
felixfbecker 8y ago
This reminds me a lot of the SUBSCRIBE method [0] in Microsoft’s WebDAV extensions (I think this is used for EAS?). You pass a Call-Back header with a URL that gets called with NOTIFY [1] [0] https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa143117(v%3dexchg.65) https://docs.microsoft.com/en-us/previous-versions/office/de... [1] https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa142938(v%3dexchg.65) https://docs.microsoft.com/en-us/previous-versions/office/de...

voltagex_ 8y ago

Middleboxes and bad HTTP servers/clients would explode, I guarantee it.

friend-monoid 8y ago
But we have the PATCH method, which is... Non-standard, I think? And it works fine.
- icebraining 8y ago
  It's been a standard for a few years: https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789
lomnakkus 8y ago
Always use HTTPS?

treve 8y ago

I don't think we need more HTTP methods, unless a real case can be made for the existing ones not being good enough. The HTTP strongly discourages it. But I love the idea of topics being Uris (not just HTTP)

jcrites 8y ago

"topics" are indeed HTTP URLs: 1. Definitions Topic. An HTTP (or HTTPS) resource URL. However, you subscribe to a topic by interacting with a different "hub" URL, passing the "topic" URL as a parameter (`hub.topic`). Service discovery does appear to support HEAD requests. (See section 4.) Having a new HTTP verb for subscribing and publishing would seem like unnecessary complexity to me. Rather than ask "why not a new verb", I think a case would need to be made that a new verb is required, that the operation does not cleanly fit into the semantics of existing verbs. The existing verbs are capable of modeling quite a lot. With the protocol as they've described it, subscribing is just sending an HTTP POST to the hub URL, passing in the topic URL. That's a simple HTTP operation that a lot of clients and programs can be instructed to do easily. Requiring the use of a new HTTP verb will make interoperability difficult without apparent benefit.

dnomad 8y ago
> Having a new HTTP verb for subscribing and publishing would seem like unnecessary complexity to me. Complexity for who? Introducing a secondary "hub" resource here is just accidental complexity. If I want to subscribe to resource A why am I talking to a different resource B? And once you introduce a secondary resource now you need yet another service discovery mechanism to support discovery of these pseudo-resource hubs. (Heaven forbid using an existing service discovery mechanism like RDDL.) Honestly stuff like this is just so poorly thought out it's difficult to understand why W3C stamps approval on this crap. There's no consideration given to alternate protocols like WebSockets or XMPP and there's no attempt to layer on top of existing standards in a meaningful way (hub.secret -- really???). Worst of all there's no real understanding here of what it means for a resource to change. The entire Content-Distribution model is geared towards just one very narrow use case. It's clear the W3C is all about being "inclusive" and "moving fast" there's real fear of "overthinking" things -- but seriously if this is the result we'd probably better off with better standards once a decade then this.
- pjc50 8y ago
  New HTTP verbs require support in the web server, and all proxies along the way, while using existing ones doesn't and is just part of the normal application framework.

felixfbecker 8y ago

This reminds me a lot of the SUBSCRIBE method [0] in Microsoft’s WebDAV extensions (I think this is used for EAS?). You pass a Call-Back header with a URL that gets called with NOTIFY [1] [0] https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa143117(v%3dexchg.65) https://docs.microsoft.com/en-us/previous-versions/office/de... [1] https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa142938(v%3dexchg.65) https://docs.microsoft.com/en-us/previous-versions/office/de...