Contact PUT

[imbstack]

Proposed changes

Should approximately finish #55 (although there are a few discrepancies to clear up now that I look) Maybe worth doing in a followup though

Types of changes

What types of changes does your code introduce?

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the guides
• I have followed the Mozilla Lean Data Policies
• Lint and tests pass both locally and on the cicd with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Further comments

Use this space for additional comments, complications, learnings, alternatives,...

[jwhitlock]

Thanks @imbstack! I tried this in the swagger API. It is challenging due to issue #105, but my basic tests worked (add a minimal contact, update that contact).

The two big issues I see are the PUT path (/ctms vs /ctms/{email_id}), and the failing tests.

I envisioned this endpoint's strategy as "omitting a parameter means leave it alone", where instead it has the strategy of "make it look like what I sent you". That means that you always have to GET the existing object to update, and last writer wins. I think that is less useful for the way Basket uses it, but we can make it work.

[jwhitlock]

Thanks @imbstack!