Serparation of concerns between HTTP API and GUI that calls it

Question

I am using an HTTP API. This is a sort of Home Automation API in a sense. Really more of a RPC interface but it is expressed as HTTP API.

It supports PUT: http://server/resource BODY;Json = { 'action': 'value' }

OK. Now I want to create a GUI (HTTP/CSS in my case but that does not matter for this question). The GUI will have a button to invoke each of these actions. So the GUI needs:

1. A list of valid actions (clearly API responsibility)
2. The 'value' to PUT for 'ACTION' (API Responsibilty)
3. An icon for each button (??? Who is responsible)
4. A Text Label for each button' (??? Who is responsible)

I don't want to have to compile/rebuild the Gui if the API changes so I want to store the button config in some sort of meta data.

So, the question is; to maintain a separation of concerns, whose responsibility is this metadata. The API or the GUI.

If I put it in the API then multiple GUI's can GET this metadata and all look similar and will react to changes in the API.

But, icons and such really feel like GUI data.

I could really use some help understanding the best practices for how to split these layers and still maintain a good separation of concerns.

Thanks in advance

Answer 1

This will require making a lot of assumptions about your application, but it sure sounds like these are really GUI concerns, and should remain in the GUI. If you start doing things like making the API responsible for the display of the GUI you are no longer creating an API, you are creating a web application.

Now, that being said, your API sounds like it's a little too generic, and maybe wrapping that API in a web application is the right thing to do, but that would be a pretty big deviation from your original question scope.