Combined concept + mapping REST PUT/PATCH API support

[snyaggarwal]

CRUD is separate for a concept and its mappings because each is a top-level resource, which is different from concept names, descriptions and extras which are true sub-resources. We want to allow a single PUT/PATCH request for a concept and its mappings to allow more efficient and transaction-safe processing.

Acceptance Criteria

• OCL API accepts PUT/PATCH request for a concept plus its mappings

• OCL API should reject the request if a mapping is submitted that is not associated with the parent concept

• Transaction - all or nothing - we don't want a partially created/updated set of results; either everything works or everything fails

[filiperochalopes]

You mentioned that you wanted to discuss PUT and PATCH methods; what specific issue were you referring to?

[filiperochalopes]

@snyaggarwal I am waiting for your comments so we can start working on it.

[snyaggarwal]

@filiperochalopes After thinking and organizing my thoughts I am quite clear on this. Just think there is only one condition that needs to meet -- PUT/PATCH request will require mapping ID as mandatory field in the payload.

[filiperochalopes]

@snyaggarwal What if, in the mapping list, one of them needs to be added instead of being updated? Regarding those that will be updated, I agree with using the mapping ID, but what about creating a new mapping for an existing concept using PATCH?

If I send a PUT request with just the new mapping to be added, will it delete the other mappings?

[snyaggarwal]

both in PUT and PATCH

• Update existing if ID is given
• Add new if no ID is given
• ID and "action": "__delete" is needed to delete an existing mapping.

I think assuming DELETE for what's not provided might be dangerous or unintentional (But this also violates REST PUT operation, which I am ok with :P)
action is something we already use in import to delete content, so I think we can reuse this and be explicit

[filiperochalopes]

lgtm