0

I'm somewhat new to RESTful API design practice and looking for help. The data model I'm working with details a top-level object (e.g. Book) containing a list of a nested objects (e.g. Chapters).
Each Chapter is persisted in its own right and has a simple_name field that is set to unique=True (ie. only one Chapter with Chapter.simple_name = "ch_01" may exist).

Scenario: A user POSTs a Book ("myBook_v1") containing Chapters, "ch_01", "ch_02", and "ch_03". The user then edits their book and the next day POSTs "myBook_v2" containing Chapters, "ch_01", "ch_02", "ch_03", and "ch_04". Suppose that Chapters "ch_01", "ch_02", "ch_03" are unchanged from the original POST.

Currently, since simple_name is required to be unique, the second POST does not pass uniqueness validation and an error response is returned to the user.

Question: Would the following implementation fit REST design principles? And, most importantly, is this a good (safe) design choice?

Implementation: Upon Book POST, check each Chapter.simple_name for uniqueness. If Chapter.simple_name already exists in database, skip creation. If it does not exist, create new Chapter. Return complete persisted Book with a mix of newly created Chapters and already existing Chapters. The only criteria for deciding to create new or use existing is whether or not the user-specified simple_name already exists for a Chapter in the database.

CDspace
  • 2,639
  • 18
  • 30
  • 36
klesh
  • 49
  • 9

1 Answers1

0

The idea here is to remove the uniqueness constraint by dropping the associated validator and deal with adding / updating / removing by yourself after (see Unique validation on nested serializer on Django Rest Framework)

Linovia
  • 19,812
  • 4
  • 47
  • 48