The rules are pairs of key-values with an associated monetary value. We also have a quote_rules table which stores the rules that are applied when it comes to calculating a vehicle quote.

That is, same model, different year, size or body type. For example, we can have a “2008 Honda Civic Hatchback which is a Compact car” and also a “1990 Honda Civic Hatchback which is a Sub-compact”. This model allows us very fine-grained differentiation between vehicles. And finally, each model style has many years in which they were being produced (via the model_style_years table). Styles are combinations of body types (the body_types table) and sizes (e.g. in the models table), each model has many styles (the model_styles table). in the makes table) has many models (e.g. That whole hierarchy works like this: A vehicle make (e.g. The records in the model_style_years table represent specific vehicles. The only difference is the level or certainty of the quote. If we don’t have their vehicle registered, then we leave that field unpopulated. The idea of this is that, when a customer submits a request for a quote, if we have their vehicle registered in our database, then we can populate this foreign key and link the quote with the specific vehicle that it’s quoting. This FK points to the model_style_years table which contains specific vehicle models that our system can store explicitly. It also includes a model_style_year_id field which is an optional foreign key to another table. The quotes table includes all the fields that identify a vehicle: year, make, model, body style and size. It also captures the offered quote that is, the money value that our system calculates for their vehicle. It captures all the relevant vehicle information in terms of model and condition.

It stores all the requests for quotes received from our client’s customers. The main table in our model is the quotes table. CRUD vehicle models so that overrides can be specified for them.Price overrides are used regardless of the current rules. Store and manage pricing overrides on a vehicle model basis.Store and manage rules that are used to calculate vehicle prices.Given a vehicle model and condition, calculate a price.Here’s a short list of features that we need to implement in order to fulfill that requirement: It is a REST API that allows users to provide vehicle information (year, make, model, condition, etc.) and will produce a quote of how much money our hypothetical client would be willing to pay for it. We are building the back-end component that will support that app. Our client wants to automate the process of calculating how much money to offer their customers for their vehicles, given certain information about them.

The application that we’ll be building throughout this article will address a request from a hypothetical car junker business. You can find the finished product on my GitHub. There’s a table of contents at the bottom.įirst, let’s get familiar with what we’re building. So think of this piece as a sort of tutorial or overview of the most common framework features when it comes to developing REST APIs. Along the way, I’ll touch on the most common problems that one runs into when developing such applications and how they are solved in the. So in this blog post, I’m going to chronicle my experience developing a simple but complete REST API application. So I thought of taking some time to do just that, really dive in, see what’s new, and get a sense of the general developer experience that the current incarnation of. NET 5, I think now is a great time to dive back in. NET game for a good while, but with the milestone release that is. I truly believe that this new direction can help the technology realize its true potential, since it’s no longer shackled to Windows-based environments. This is old news by now, but I’m still amazed by the fact that nowadays.

Scaffold dbcontext postgresql