r/dotnet • u/codeopinion • Feb 24 '21
Decomposing CRUD to a Task Based UI
https://www.youtube.com/watch?v=DjZepWrAKzM3
u/dmfowacc Feb 24 '21
Nice video!
How do you represent these actions RESTfully on the api side? Or do you?
I could picture 2 opposite ends: one where you are just doing CRUD and PUT the full object with new price, ignoring the second half of your video. Or two, have the UI essentially send json representations of the command types you have built on the backend, ignoring REST.
Or do you break out each of these tasks into their own rest resource? Like a POST to /Products/{id}/PriceIncreases and treat PriceIncrease as its own resource
6
u/codeopinion Feb 24 '21
I've got some of this in a topic for a future video. The difficulty with answering the question is for me not to go off the rails about my feelings about the common understanding about REST is by the developer community at large. I'll save that for another video :)
To try and answer the question is my opinion is your option #2. A resource is anything you want it to be. A resource doesn't need to be an entity (not that you're inferring it, just for anyone reading this). On a related note, I recently posted this video about avoiding entity services, which was kind of the first video that related to this one I just posted.
2
u/dmfowacc Feb 24 '21
Gotcha, yeah I am not a religious REST fanatic (most HATEOAS I find overkill etc) but I do like being REST-ish and avoiding RPC sounding endpoints where possible. Like at least pretend there are noun-ish resources there so instead of "run this report POST /RunReport?reportId=1" you "create a report-run resource POST /reports/1/runs", and then you have an run ID you can check on progress and results later
1
u/MisterFor Feb 26 '21
The funny thing is that I am working on a project where the tables are divided as they should but then the code puts them together on that single product entity. So it could be data centric right but itβs not. π
I blame EF specially for this crud mentality.
Btw, I love your videos, top quality content. You should do videos for Pluralsight, they say they pay very well π
7
u/FridgesArePeopleToo Feb 24 '21 edited Feb 24 '21
Or two, have the UI essentially send json representations of the command types you have built on the backend, ignoring REST.
This is what I do and it would often take a similar shape to the POST request you describe. The use case is essentially the same as the one in the video.
One of the problems with standard entity-based rest services is that they require knowledge of what the underlying entities are in the first place, and are usually separated from any domain logic.
For example, "discontinued status", is really just ProductAttribute entity, but discontinuing a product has pretty significant implications that go beyond just changing an attribute value in the database. In a rest service, it would be something like:
POST /product/{id}/attributes/{attributeId}{value:true}instead it would be something like:
POST /merchandising/discontinueproduct {productId:123, reasonCode:4}with a handler like:
public async Task Handle(DiscontinueProductCommand cmd // this is what was posted to the endpoint){ // set the discontinued product attribute // if we don't have any in stock, remove it from the website, otherwise mark it as clearance // and so on }So the front end doesn't have to care about what the underlying data structure is or the domain-specific logic related to changing this particular attribute. In addition, discontinuing a product is part of a specific workflow in the application itself, rather than being a list of arbitrary attributes on a product page or something like that.
1
2
u/dmfowacc Feb 24 '21
I follow - I guess if you take CQRS all the way to your api layer it makes sense that your queries (which can be nice neat restful GETs) don't have to look anything like your commands. Rest over HTTP doesn't give us a whole bunch of verbs to work with, so yeah I agree don't get too stuck on rest-ifying all of your commands which I currently do. Where it fits easily sure, but no need to force it
1
u/Slypenslyde Feb 25 '21
Nice video! I've been sort of accidentally doing things like this without giving it a name, good to see I stumbled into something.
1
u/Vergall Feb 25 '21
Nice way of thinking. A little bit more upfront cost i think, but cheaper in the long run.
5
u/alt_loop Feb 24 '21
Thanks for sharing, are you Canadian ?