THIS IS SO EXCITING! Thanks Helene!
I'm wondering if it's worthwhile doing OpenRosa headers when they don't add much and I'm thinking out strategy should be to call this part of a new API standard that wraps OpenRosa rather than extending it. More on that in a separate post... But yeah let's nix the OpenRosa stuff?
By extension of the above, yes I think it's fine to go with JSON.
I like client-settings if we are thinking of a "client settings" as a singular resource. The word "settings" is always confusing there because it is both a collection of individual settings and a singular resource (the collection).
Using dashes is a break from OpenRosa which used lowerCamel. But I'm fine with that. Also Central appears to use dashes, as does NEMO.
Thanks for matching the QR code structure. That's a big win.
Does this mean the spec should also require support for a HEAD request? Or is the idea that Collect would GET the whole thing but only apply the settings if they had changed? Kind of confused...
I think working out when Collect asks for settings is a separate discussion. But one thought did come to mind that could have impact here: folks may end up using both this feature and the QR code feature, right? The latter to initially config the device with just the server and credentials, and then relying on settings push from then on? This is intricate but I think it makes sense.
Another possibility is that an org may have a whitelabeled build of Collect that includes a certain default server and initial, generic "bootstrap" credentials. When Collect is first installed or opened it may call the server to get its proper settings including the correct username and password for an individual enumerator the server selects. This could actually be a very powerful way of setting up a large fleet of devices without having to scan barcodes over and over again. All you'd have to do is install and run the app. The server could e.g. decide to associate phone #123 with user X, phone #124 with user Y, etc., and provide some really nifty web-based UI for showing how all the devices have been allocated so they can be labeled and handed out. But this would require the incoming GET request to identify the device somehow. So can we include the new Collect: style device ID in the GET request params? Compliant servers can then decide to use it or not.
Another option would be to lean into REST and treat the device ID as the identifier for the resource, so like /client-settings/Collect:ABCDEFGHIJKLMNOP. This seems semantically more correct than putting it as a QS param, because it's not really a filter. Servers not using the device ID can just ignore it and return the same settings for each device.
Anyway lots to be discussed here but yeah, super exciting, and thanks a ton!