Design the API

Dilemmas while designing API

On the sign-in screen, the user will submit a name and a language choice. Where does the list of language options come from? We could have the front-end application contact the server to find out the valid language options to show. This requires an additional API request, but we’ll be able to update the list without resetting all clients. Or, we could hard-code the options into the front-end application, making them part of the code itself. To update the list, we need to make sure every browser gets the new client. To simplify this, we could have every API response also return a field, indicating if there’s a new client available, although this goes against the spirit of the REST API because it contaminates each route with unrelated responsibilities. This sort of design question about how updates are handled is an important part of API design. Since we anticipate that language options will only rarely change, we will leave the options hard-coded in the client.

Sign-in screen methods

What is the resource and method most appropriate for the response from this first screen? Since ...