Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
Are you stating that the endpoint, depending upon versions should be;
/shoppingbasket/user/v1/fred (original)
/shoppingbasket/user/v2/fred (this json/DTO object may have more attributes).
? I think you are.
Thinking of this in .Net Core/.Net Web API, these are separate endpoints and they have to be because they are returning different objects. Like Martin says, seems like double the pain but I get your idea.
I have seen certain APIs do something like this (JIRA)
server/version/shoppingbasket/fred
This makes sense as you could maintain separate code bases but simply deploy the URL without screwing up the routing. In your client request, the base URL can be configured. Clients know what they are signing up for.
I'm really saying you don't want to do v2. Have /shoppingbasket/user/fred return an object, and the caller be forgiving about new attributes. If you need truly breaking changes, then you do need a v2, but it's a last resort and an indication you've broken something.
HTTP (or at least REST) doesn't make this sort of thing easy.
Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
Hi Dave, I thought about this some more. It makes sense. Automappers can be strict or optimistic, so they can rigidly enforce a data structure in the client.
My main concern with your approach is;
We are assuming no fields/substructures are ever removed. A protocol is simply a common set of rules for communication. The parts of speech can be part of a protocol toolkit and can never be removed. In the data based example, the data is not a protocol - it is subject to change, can see fields removed. In our day and age, we are becoming ever sensitive to risk upset to others and are constantly changing policies etc.
What might have to happen, is the protocol (endpoint in your system) delivers simply a validation object and a version object. This tells the client what it has to conform to. There could be an additional validation end point. This is quite neat because it lets the validator end point say which formats it conforms to?
REST is itself, a protocol, yet the packets are unknown to the protocol. A bit like a pipe doesn't care what is shoved down it, as long as it fits. Plumbers know that a soil pipe is a protocol, a mains pipe provides water - they don't test what goes through it when they connect a toilet or a tap. A manufacturer can quite rightly say, the dishwasher was never designed to run on the waste pipe protocol.
Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
Hi Dave, trying to understand this.
Are you stating that the endpoint, depending upon versions should be;
/shoppingbasket/user/v1/fred (original)
/shoppingbasket/user/v2/fred (this json/DTO object may have more attributes).
? I think you are.
Thinking of this in .Net Core/.Net Web API, these are separate endpoints and they have to be because they are returning different objects. Like Martin says, seems like double the pain but I get your idea.
I have seen certain APIs do something like this (JIRA)
server/version/shoppingbasket/fred
This makes sense as you could maintain separate code bases but simply deploy the URL without screwing up the routing. In your client request, the base URL can be configured. Clients know what they are signing up for.
Anyway, interesting thoughts.
I'm really saying you don't want to do v2. Have /shoppingbasket/user/fred return an object, and the caller be forgiving about new attributes. If you need truly breaking changes, then you do need a v2, but it's a last resort and an indication you've broken something.
HTTP (or at least REST) doesn't make this sort of thing easy.
Hi Dave, I thought about this some more. It makes sense. Automappers can be strict or optimistic, so they can rigidly enforce a data structure in the client.
My main concern with your approach is;
What might have to happen, is the protocol (endpoint in your system) delivers simply a validation object and a version object. This tells the client what it has to conform to. There could be an additional validation end point. This is quite neat because it lets the validator end point say which formats it conforms to?
REST is itself, a protocol, yet the packets are unknown to the protocol. A bit like a pipe doesn't care what is shoved down it, as long as it fits. Plumbers know that a soil pipe is a protocol, a mains pipe provides water - they don't test what goes through it when they connect a toilet or a tap. A manufacturer can quite rightly say, the dishwasher was never designed to run on the waste pipe protocol.
Understood Dave. Will think about it some more. Thanks.