Update MARC records via quick-marc API

[justinlittman]

This allows taking advantage of optimistic locking.

See https://dev.folio.org/reference/api/#mod-quick-marc

[lwrubel]

Here's how to create a holdings record with permanent location SUL-SDR and holdings type electronic: https://github.com/sul-dlss/folio_client/issues/33

[justinlittman]

API documentation:

• https://s3.amazonaws.com/foliodocs/api/mod-quick-marc/s/records-editor-async.html
• https://s3.amazonaws.com/foliodocs/api/mod-quick-marc/s/records-editor.html

The use case for this is retrieving an existing MARC record from Folio, modifying the 856 fields, and posting back to Folio. Creating a holding record is outside the scope of this ticket.

Given the limited use case, I think it is OK for the consumer of the client to operate on the raw quickmark JSON record structure, rather than something like MARC.

Thus, the client should support getting the quickmark JSON record for a MARC record given a HRID:

resp = connection.get('/records-editor/records', {externalId: '5108040a-65bc-40ed-bd50-265958301ce4'}, {"x-okapi-token": config.token})
resp_json = JSON.parse(resp.body)

In this example, the externalId is the id of the inventory instance record (not the HRID).

The client should support posting back the modified quickmark JSON record:

parsed_record_id = resp_json['parsedRecordId']
connection.put("/records-editor/records/#{parsed_record_id}", resp_json.to_json, {"x-okapi-token": config.token})

The client should handle all errors, including a 409 indicating an optimistic locking error.

There are a variety of ways this could be structured but one possibility is something like:

def edit
   resp_json = <get the record>
   yield resp_json
   <post the record>
end

I have a Jupyter notebook that shows the use of the quickmark API in case it is helpful.