Skip to content

lark: Refactor response serialization to use a `RecordSerializer`

tamsin woo requested to merge lark-serializer into master

Connected to #31 (closed)

Local Checklist

  • Read our Contributing guide (for newcomers)
  • Tests written and passing locally?
  • Code style checked?
  • QA-ed locally?
  • Rebased with master branch?
  • Configuration updated (if needed)?
  • Documentation updated (if needed)?

What does this Merge Request do?

A RecordSerializer is introduced for building response bodies from Concept and other authority record models. The idea is that, given the correct options, a serializer and a parser should be able to round trip records (i.e. a record serialized and then parsed should yield an identical Concept object).

For now, the implementation is hard-coded. It's a straight refactor of the behavior previously in RecordController#show and #create.

Why are we doing this? Any context of related work or Epic?

The main goal here is to clarify our expectations for parsing/serializing records for the API. This should help us continue to develop behavior around create and update requests.

References #31 (closed)

Where should a reviewer start?

Start with the changes to RecordController. Note that the controller's tests don't change, and only a minor change is needed in the API specs.

Merge request reports