I've worked on many enterprise projects, primarily with server-driven frameworks like Blazor Razor, or just on the backend API. Currently, I'm prototyping a project to transition an existing Razor app into React at my new job, and I'm pretty comfortable with both React and ASP.NET. My approach typically involves crafting API endpoints tailored for specific pages or components, essentially following a Backend for Frontend (BFF) pattern.
I'm trying to figure out the best way to organize backend endpoints for server-side calculations, such as pricing, that users need to see in real-time while filling out a form. Take, for example, a booking system for hotel rooms. If a customer is creating a booking, the form needs to fetch certain data to populate dropdown menus – which means I'll need an endpoint like `/bookings/create/form-data`.
As the user inputs information (with debouncing to avoid unnecessary calls), I need to provide a preview of the price, achievable only through server-side calculations, prompting another endpoint call like `/bookings/create/price`. Finally, there's the endpoint for the actual booking creation: `/bookings/create`.
Are there any thoughts or experiences you could share on this? Is this structure overkill? Could I merge the first two endpoints into one to streamline things? Perhaps calling it `/bookings/create/preview-data` would be better? Of course, the final `CreateBookingEndpoint` would ensure that the calculations for price and shipping happen again as a source of truth.
I'm just looking for practical insights and possible pitfalls based on real-world experiences!
5 Answers
When designing your APIs, think of the HTTP requests as actions. For example, to create a booking, consider a `POST /booking`, which implies you're creating something. This returns the generated data. If modifications are needed later, you can use a `PATCH /booking`. Visualizing your API actions helps clarify their purposes.
Use verbs like CREATE, UPDATE, and RETRIEVE to guide your endpoint design. For your booking example, it's all about structuring the data logically, perhaps as:
- booking
- id
- name
- status
- pricing
Your idea of separating the preview and create endpoints is quite normal. Use dedicated endpoints for form data and preview so that they don't interfere with each other. Following Microsoft's BFF approach, focusing backend interactions around the frontend's needs is a great strategy!
You're on the right track with your separation of concerns. Having distinct endpoints for data retrieval, price preview, and the final create command will help prevent issues. Just ensure both preview and create share the same backend logic to maintain accuracy.
I suggest holding off on creating endpoints until your data structure is finalized. When calculating prices server-side, avoid issues by ensuring the complete object graph is saved in one go. To preview prices without saving initially, set up an endpoint that returns the calculated price based on the input parameters without affecting the database. This way, you can display real-time pricing while ensuring data consistency during the final submission.
Definitely, and remember to keep your calculations tied to the same price service to avoid discrepancies between preview and create!
Treat `/preview` as a dry run of `/create`. Use the same input structure and validation, but without any side effects. This keeps the user experience consistent and manageable. It sounds like a standard practice in similar setups.
Exactly! Always group related fields into child objects based on their purpose to keep everything organized. For instance, you could have `booking.customer`, `booking.stay`, and `booking.pricing`. Makes handling data a lot smoother!