4 ms·

But DNS allows for redirection wrt IPs. How does HATEOAS do the same? First, you already have DNS, and can abstract wrt existing URL structure. second, you sti

by Chris2048 5y ago

But DNS allows for redirection wrt IPs. How does HATEOAS do the same? First, you already have DNS, and can abstract wrt existing URL structure. second, you still need stable references to services in order to identify them, and they in turn need to have stable structure - Hence the only thing you can change is the top-level stuff? Why is that important?

naasking 5y ago
> But DNS allows for redirection wrt IPs. How does HATEOAS do the same? I gave a code sample above. The service's entry point exports a map of unstable URLs to stable names, just like DNS exports a map of unstable IPs to stable names. What I described is the most basic form of HATEOAS, but it also allows hierarchical structuring, ie. you can discover more URLs via any path through a hierarchy of hypermedia returned by URLs from the entry point. > First, you already have DNS, and can abstract wrt existing URL structure DNS abstracts IPs not URLs. You could come up with an encoding where you map URLs to subdomains, but now you're lifting application logic to influence infrastructure policy, where your devs are now messing with nameservers instead of just sticking to their HTTP application, and you're tied to DNS TTL instead of application-specific caching policies, and DNS insecurities (no TLS). For instance, with HATEOAS I can make a resource permanent, or live only a few seconds, and these are application-level policies I can define without leaving my coding environment. DNS just can't give you this control, so trying to shoehorn the flexibility that HATEOAS gives you into DNS is putting on a straightjacket.
- Chris2048 5y ago
  But IPs are network-based so inherently unstable. Why are names better wrt stability than URLs? i.e. why is ref <myFooService> better than www.myDomain.com/service/myFooService ? Unlike IPs, URLs can be just as abstract as names, no? > it also allows hierarchical structuring This is what I meant by "the only thing you can change is the top-level stuff" - is this important enough to require the extra level of abstraction? For whose benefit is the restructuring if the stable names all share the same namespace anyway. > you can discover more URLs Is this a manual user hitting these API endpoints, or a client? Why is it useful that a client can be given different entry paths? > where your devs are now messing with nameservers current service discovery solutions don't require this. The name server just points to a single proxy.
  - naasking 5y ago
    > i.e. why is ref <myFooService> better than www.myDomain.com/service/myFooService ? Because the latter is less flexible. I've expanded on this here [1], but for the short version, you can change the reference of <myFooService> without regard for location or based on any number of other application-specific policies, without having to host everything behind a single DNS entry. [1] https://news.ycombinator.com/item?id=29017134 https://news.ycombinator.com/item?id=29017134
    - Chris2048 5y ago
      > you could immediately respond by returning URLs for a different geolocated service, or round-robin among a bunch of locations Is this not possible with a proxy and a (non-perm) redirect? > without having to host everything behind a single DNS entry But your entry point will still need to be a single entry! It sounds more like you want extra semantics around DNS - e.g. have some entry point provide latest mirrors, localised servers etc; but this would require extra logic in the client app that could be a new protocol at a lower level. I suppose that makes sense if you are working at the application level, but as an industry standard I'd sooner have a lot of this stuff lifted to the non-application layer. That said, I still don't get the HATEOS aspect; Is the reason you'd have to follow references so that there is no single "stateful" collector of the state of (other) backend services?

naasking 5y ago

> But DNS allows for redirection wrt IPs. How does HATEOAS do the same? I gave a code sample above. The service's entry point exports a map of unstable URLs to stable names, just like DNS exports a map of unstable IPs to stable names. What I described is the most basic form of HATEOAS, but it also allows hierarchical structuring, ie. you can discover more URLs via any path through a hierarchy of hypermedia returned by URLs from the entry point. > First, you already have DNS, and can abstract wrt existing URL structure DNS abstracts IPs not URLs. You could come up with an encoding where you map URLs to subdomains, but now you're lifting application logic to influence infrastructure policy, where your devs are now messing with nameservers instead of just sticking to their HTTP application, and you're tied to DNS TTL instead of application-specific caching policies, and DNS insecurities (no TLS). For instance, with HATEOAS I can make a resource permanent, or live only a few seconds, and these are application-level policies I can define without leaving my coding environment. DNS just can't give you this control, so trying to shoehorn the flexibility that HATEOAS gives you into DNS is putting on a straightjacket.

Chris2048 5y ago
But IPs are network-based so inherently unstable. Why are names better wrt stability than URLs? i.e. why is ref <myFooService> better than www.myDomain.com/service/myFooService ? Unlike IPs, URLs can be just as abstract as names, no? > it also allows hierarchical structuring This is what I meant by "the only thing you can change is the top-level stuff" - is this important enough to require the extra level of abstraction? For whose benefit is the restructuring if the stable names all share the same namespace anyway. > you can discover more URLs Is this a manual user hitting these API endpoints, or a client? Why is it useful that a client can be given different entry paths? > where your devs are now messing with nameservers current service discovery solutions don't require this. The name server just points to a single proxy.
- naasking 5y ago
  > i.e. why is ref <myFooService> better than www.myDomain.com/service/myFooService ? Because the latter is less flexible. I've expanded on this here [1], but for the short version, you can change the reference of <myFooService> without regard for location or based on any number of other application-specific policies, without having to host everything behind a single DNS entry. [1] https://news.ycombinator.com/item?id=29017134 https://news.ycombinator.com/item?id=29017134
  - Chris2048 5y ago
    > you could immediately respond by returning URLs for a different geolocated service, or round-robin among a bunch of locations Is this not possible with a proxy and a (non-perm) redirect? > without having to host everything behind a single DNS entry But your entry point will still need to be a single entry! It sounds more like you want extra semantics around DNS - e.g. have some entry point provide latest mirrors, localised servers etc; but this would require extra logic in the client app that could be a new protocol at a lower level. I suppose that makes sense if you are working at the application level, but as an industry standard I'd sooner have a lot of this stuff lifted to the non-application layer. That said, I still don't get the HATEOS aspect; Is the reason you'd have to follow references so that there is no single "stateful" collector of the state of (other) backend services?