3 ms·

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/se

by 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

> 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?