Background: There is a UI Client and REST Webservice.

The user interface form allows you to create a complex object. The complex object is composed of primitive types (string, integers,...), and nested types (reference types). Each of the nested types is accessible through a REST resource endpoint as well as the complex object.

The user can create a complex object in the user interface form, and for each of the nested objects he can link it with a new nested object (create it on the same form screen) or link it with existing nested object based on ID.

  • All objects are persisted in the DB. Each in its own table and relationships are defined (ORM - EF).

The Problem: The form submits operation should be atomic. If the user submits the form, it's all or nothing operation. It's also important to note that: If a complex object was linked with a new nested type, and something went wrong while creating the object the new nested type will not be created as well!.

I came with few options to solve it, but I would like to know if there is a better approach. The only difference between those options is the HTTP BODY model structure

Solution Approaches:

  1. Create a new complex object through a POST operation against the complex object resource, with the body containing the entire object model. In that case, the client(UI) should send the entire nested objects with their id even if they already exist.

  2. Create a new complex object through a POST operation against the complex object resource. The body will only contain ids as a reference to the nested objects. In that case, a transaction should be created, because a user can fail to create the complex object and we would have to rollback the nested objects.

  3. A mix of (1), (2), the body will contain ids and actual object nested types, and the user will populate each based on the required needs.

There are drawbacks for each of the options:

With option 3, it will be complicated to validate and maintain the object creation.

Option 2 involves managing distributed transaction.

Option 1 seems like the preferred approach. However, the noticeable drawback here is that you always need to send the entire object (even if the object is already created, you will have to first fetch it via GET operation, and then later submit it on the POST operation).

What do you think is the right solution here?

I'm using Asp.Net WebApi as the WebService Framework, Entity Framework as the Database Layer, and React-JS on the frontend.

  • How large is the entire object? – Robert Harvey Feb 26 '18 at 22:12
  • Shouldn't have performance issue. Composed of ~ 30 Properties (about 50% are small reference objects) – Omri L Feb 26 '18 at 22:59
  • Then why would sending the entire object be a drawback? – Robert Harvey Feb 26 '18 at 23:00
  • That's is my preferred option, just wanted to know if there is a better one. Because the ideal would be to mix between IDs & Objects. – Omri L Feb 27 '18 at 0:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.