lark: Refactor response serialization to use a `RecordSerializer`
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.