MongoDB via WebAPI Question
-
I'm running an ASP.Net WebAPI that reaches into a MongoDB on the server. When adding an entity, how would you return the newly added entity Id (Guid) to the client side? I could return the Entity that was passed in with the new Id on it, but tha seems excessive. Would you return the Guid?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I'm running an ASP.Net WebAPI that reaches into a MongoDB on the server. When adding an entity, how would you return the newly added entity Id (Guid) to the client side? I could return the Entity that was passed in with the new Id on it, but tha seems excessive. Would you return the Guid?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
If you're building a RESTful CRUD application, then don't return either. Return a 201 status and let the client system re-query as necessary/appropriate. If it absolutely damages your soul not to return something other than a status, then just send back the ID, but you shouldn't really be serving up anything from a PUT or POST, let alone an entity.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
If you're building a RESTful CRUD application, then don't return either. Return a 201 status and let the client system re-query as necessary/appropriate. If it absolutely damages your soul not to return something other than a status, then just send back the ID, but you shouldn't really be serving up anything from a PUT or POST, let alone an entity.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
How would the client know what to query? What if I call AddEntity with two identical entities? They both end up with unique Id's, but everything else could be the same. Or, multiple clients all add records at the same time? Requerying doesn't tell you which one YOUR client added. And, truthfully, it seems excessive to requiry just because an Add was done. Another round trip to the server?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
How would the client know what to query? What if I call AddEntity with two identical entities? They both end up with unique Id's, but everything else could be the same. Or, multiple clients all add records at the same time? Requerying doesn't tell you which one YOUR client added. And, truthfully, it seems excessive to requiry just because an Add was done. Another round trip to the server?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Actually, you've pushed me back to the RFC and, my bad, including the ID with a 201 is the right answer. I need to go revisit some work that I just did :/ [HTTP/1.1: Method Definitions](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) As far as multiple adds, that's a modelling issue. If it's allowable, use PUT. If it's not, use POST and make sure your model checks against field combinations that should be unique. Worst case scenario, use a wrapper with a unique identifier (such as a transaction ID) to avoid multiple inserts. All that said: when working with REST you should not think of efficiencies in terms of round trips. REST apps are chatty. Instead, efficiencies lie in conformance to standard providing a consistent interface, and providing ways to query and slice up collections effectively.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Actually, you've pushed me back to the RFC and, my bad, including the ID with a 201 is the right answer. I need to go revisit some work that I just did :/ [HTTP/1.1: Method Definitions](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) As far as multiple adds, that's a modelling issue. If it's allowable, use PUT. If it's not, use POST and make sure your model checks against field combinations that should be unique. Worst case scenario, use a wrapper with a unique identifier (such as a transaction ID) to avoid multiple inserts. All that said: when working with REST you should not think of efficiencies in terms of round trips. REST apps are chatty. Instead, efficiencies lie in conformance to standard providing a consistent interface, and providing ways to query and slice up collections effectively.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
OK, but as far as this...
Nathan Minier wrote:
As far as multiple adds, that's a modelling issue.
What I meant was there could be any number of clients adding records at the same time. If you had to requery after YOUR instance did an add, you could get back any number of records added by ANY client instance since you did the add. You would have no way of kowing what record YOUR client added versus other clients. Not sure what Modeling has to do with this
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
OK, but as far as this...
Nathan Minier wrote:
As far as multiple adds, that's a modelling issue.
What I meant was there could be any number of clients adding records at the same time. If you had to requery after YOUR instance did an add, you could get back any number of records added by ANY client instance since you did the add. You would have no way of kowing what record YOUR client added versus other clients. Not sure what Modeling has to do with this
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
We're talking cross purposes then. As I said in the last post, I was mistaken about returning the ID of the added object along with the 201 code. That's why I posted the link for the standard as well. I assumed you were talking about multiple clients adding unique entities from the way that you worded it. That would be a modelling issue.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
I'm running an ASP.Net WebAPI that reaches into a MongoDB on the server. When adding an entity, how would you return the newly added entity Id (Guid) to the client side? I could return the Entity that was passed in with the new Id on it, but tha seems excessive. Would you return the Guid?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
If it were me, I'd return the guid so the client side could requery as needed. If you're somehow persisting the newly added data (in a session var?), i'd return the guid and add it to the data.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
If it were me, I'd return the guid so the client side could requery as needed. If you're somehow persisting the newly added data (in a session var?), i'd return the guid and add it to the data.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013It's a WPF app, which creates a new entity and sends it to the API. When the API call returns, I am now passsing back the Guid and assigning the new entity. Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.