This is the scenario: A company will offer information in the form of images and characters and htmls-iframes (coupons, clothing, products) so that your customers (stores, wholesalers, retailers, etc.) insert into their websites. That is, in addition to data there are some business rules, product images of each client, (the client wants to display the soap X in one way and customer B wants the image of soap X to be otherwise.)
My approach is to create an api that will offer endpoints to your customers.
The API will be RESTful, so I was doing a search on this post to better understand good API building practices.
My question is about the operationalization of this service. Where to put the business rules? Inside the API?
In my understanding the API, in the end it should work, only as an interface that provides access to the database, serving end-points to do CRUD operations, and returning JSON responses, only.
But the cleintes need some iframes, that is, they need the data they restore from the database and some more HTML elements or images.
So here's my question. Should the API return HTML? Is this a good practice? Will it be legal for the later maintenance? Or should we follow the green path of the drawing below or go straight to the API (orange path)?
In this case the green path is to create a service that would consume the API endpoints and insert the business rules and HTML into it. In this scenario this service (Microservice?) Would not be an API but would be acting as one, because for client 1 or 2 they would only need those endpoints to be used on their web sites.
I made this drawing below to explain better:
