I'm writing a RESTful webservice to upsert and fetch my application's configuration. There will only ever be one document/record, as this is global configuration. My question is how do I fit this into RESTful standards?
For the upsert, is a controller method of "create" or "update" most appropriate (and a verb of POST or PUT respectively)?
For the fetch, is a controller method of "index" or "show" more correct? If the former, is it acceptable to return a single object or should it be an array with a length of one? For the latter, would it be acceptable to have the route exclude the id parameter (since there's always one and it's not necessary)?
Am I overthinking this, or putting too much emphasis on "REST compliance/consistency"? Or maybe the entire thing is wrong, and I shouldn't be writing this service. I should mention that this API is more internal than anything, just what our front-end uses to communicate with the back-end. So while there's no third-parties to worry about, I still want the maintenance developer to not be confused.
I don't think it's a problem. Here's how I would design this API:
GET /api/configuration - get the configuration
PUT /api/configuration - update the configuration
PATCH /api/configuration - partially update the configuration