3 ms·

> for example publishes an endpoint discovery document. This is much easier than building a versioning-layer into your application router. How is that differen

by antpls 8y ago

> for example publishes an endpoint discovery document. This is much easier than building a versioning-layer into your application router. How is that different than having only 1 version of the API and updating it? Clients code will still break if a structural data change is pushed (for example, removing a field from the responses)

geocar 8y ago
(Perhaps a question for the mods: Why are so many of antpls's comments flagged/dead? Their other behaviour doesn't seem malicious, and this seems like a reasonable question to me even if it doesn't directly address my comment.) > How is that different than having only 1 version of the API and updating it? Using a service discovery document makes it easier to put /v1 and /v2 on separate servers/domains instead of putting both on all the servers/domains. Serving the service discovery document is cheaper than having your front-end server route all requests to backend systems (like using nginx or an Amazon ELB in application mode). Putting applications on different domains is desirable if /v2 has performance gains (or cost gains) obtained by using the new protocol. Or if they're separate codebases. > Clients code will still break if a structural data change is pushed (for example, removing a field from the responses) It's very difficult to predict how a client will react if you haven't seen/vetted their implementation, but there are things we can do that go beyond service discovery. For example: My advertising service allows publishers (people who make web pages and content) to choose how to render my advertisers' ads in those pages. They do this via a server-side call -- I don't do any tracking of this, but I want to be sure that the client is doing the right thing because I'm still representing the brands. I can look at the web page and sign off on it, but I want to make sure that it'll support a wide range of ads -- including ones I haven't thought of. So I put a lot of energy into patterns like fuzzing the clients, and doing things that I hope will require they do things securely: - I require retries so users always get an ad - I randomly giving them a bad SSL certificate -- one that if they accept, I block their account. I usually only do this during onboarding or for my crawlers (recognised by IP) which check for sneaky stuff. - I require certain utf8 characters to make sure the query is utf8 encoded - I randomly insert random fields to make sure I can add new ones later - I randomly reorder fields in the response to make sure they're not counting I think that if you do all these things, and perhaps other things, and clients are used to it then you probably can have just one version of the API and update it. But this is hard work, and the enterprise is not (in my experience) very fond of hard work.

by antpls 8y ago

geocar 8y ago

(Perhaps a question for the mods: Why are so many of antpls's comments flagged/dead? Their other behaviour doesn't seem malicious, and this seems like a reasonable question to me even if it doesn't directly address my comment.) > How is that different than having only 1 version of the API and updating it? Using a service discovery document makes it easier to put /v1 and /v2 on separate servers/domains instead of putting both on all the servers/domains. Serving the service discovery document is cheaper than having your front-end server route all requests to backend systems (like using nginx or an Amazon ELB in application mode). Putting applications on different domains is desirable if /v2 has performance gains (or cost gains) obtained by using the new protocol. Or if they're separate codebases. > Clients code will still break if a structural data change is pushed (for example, removing a field from the responses) It's very difficult to predict how a client will react if you haven't seen/vetted their implementation, but there are things we can do that go beyond service discovery. For example: My advertising service allows publishers (people who make web pages and content) to choose how to render my advertisers' ads in those pages. They do this via a server-side call -- I don't do any tracking of this, but I want to be sure that the client is doing the right thing because I'm still representing the brands. I can look at the web page and sign off on it, but I want to make sure that it'll support a wide range of ads -- including ones I haven't thought of. So I put a lot of energy into patterns like fuzzing the clients, and doing things that I hope will require they do things securely: - I require retries so users always get an ad - I randomly giving them a bad SSL certificate -- one that if they accept, I block their account. I usually only do this during onboarding or for my crawlers (recognised by IP) which check for sneaky stuff. - I require certain utf8 characters to make sure the query is utf8 encoded - I randomly insert random fields to make sure I can add new ones later - I randomly reorder fields in the response to make sure they're not counting I think that if you do all these things, and perhaps other things, and clients are used to it then you probably can have just one version of the API and update it. But this is hard work, and the enterprise is not (in my experience) very fond of hard work.