Getting /records at a particular entry

[pmackay]

Its not clear to me from the spec, is/will there be a way to get /records tied to a specific entry?

The use case would be a client wanting to use the data at a given snapshot and not have the data change when a new entry is added.

[philandstuff]

@pmackay there is only one /record for an entry; the one identified by the given primary key of the entry. For example, the /record for the country register entry

{"country": "GM", "name": "Gambia, The"}

is /record/GM.

This follows from the definition of a record.

EDIT: oops, this was sloppy language. The json document above is an item. So you have to first get the item for the entry, then find the record for the primary key in the item.

[pmackay]

Sure, but how to get all records via /records endpoint at a specific point in the entry list?

[philandstuff]

I'm not sure I understand the question.

Do you mean "how do I get a list of all records as it was at a particular point in time, identified by number of entries in the register?" That's not something we currently support; if you wanted it you'd have to download the register and make your own index.

If I have understood you correctly, and if there is interest in this functionality, I'd be interested in hearing use-cases. Can you give examples of where you might use it?

(ping @michaelabroschomb)

[pmackay]

how do I get a list of all records as it was at a particular point in time, identified by number of entries in the register?

Yes. Another way of looking at it is similar to the way one can reference a particular commit/release/tag of a project on Github with a URL. Currently the /records endpoint seems to be the git equivalent of HEAD.

To make up a contrived example, say the register of food-premises-types was going to be used directly by a council in a form for requesting a food premises license. At some point, a new entry might be added to handle food delivery by drone (insert own futuristic example here). Councils however might not want to immediately have their form include this new type without doing an internal review about their policy for drone delivery. But they do like to call the register API directly rather than downloading data cos its easier for their webforms. So having an endpoint that returns a snapshot rather than always the latest would be helpful.

[psd]

What is the use-case for this scenario?

[pmackay]

@psd I had hoped the above comment suggested one. Here's another couple of ideas:

Councils might want to use a register of commonly used waste containers or bulky items they will collect. If they want to:

• build web forms that dynamically query the register directly (rather than having to download and separately store a copy)
• control the list such that if the register changes, their lists dont automatically change, because they want to verify the change first

is that a use case you would consider valid and worth supporting?

[psd]

Ah, that's clearer. I think you're asking for versioning of enumerated types.

Hiding changes made to register data is something we do not support in the register, they're definitely the concern of the client.

I'm in the process of expanding the versioning and extensibility section to explain this and some of the other evolutions which register data and the register API may make and which clients must be resilliant to.