Returning HTML to an API would be good practice? Microservice?

Asked

Viewed 447 times

2

This is the scenario: A company will offer information in the format of images and characters and htmls-iframes (coupons, clothing, products) so that its customers (stores, wholesalers, ruffians, etc.) insert in their websites. That is, in addition to data there are some business rules, pictures of each customer’s products, (the customer wants to display the X soap in one way and the customer B wants the image of the X soap 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 regarding the operationalization of this service. Where to put the business rules? Inside the API?

In my understanding the API, ultimately 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 cleintes need some iframes objects, 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 good practice? Will it be legal for subsequent maintenance? That is to say we should follow the green path of the drawing below or go straight to the API (orange path)?

In this case the green way is to be created a service that would consume the endpoints of the API and in it we could insert the business rules and the Htmls. In this scenario this service (Microservice?) would not be an API but would be acting as one, as for client 1 or 2 they would only need these end-points to be used on their web sites.

I made this drawing below to explain better: inserir a descrição da imagem aqui

api microservices

1 answer

2


Should the API return HTML? This is good practice?

And why wouldn’t it be?

If you are speaking explicitly about REST Apis, the answer is probably nay because you wouldn’t be returning objects in some kind of data envelope (JSON, XML, etc.)

But if your API has non-SULE aspects, nothing prevents you from returning content text-html from a given endpoint.

  • That’s correct, it could return HTML and tbm JSON or XML. But would that be a good practice? In other words, I’d be sending the business rules into the API. This would increase complexity and consequently increase the complexity of tbm maintenance. So it would be a better approach to create a micro service to keep the API leaner?

  • @zwitterion it is possible to argue that the opposite would be happening - complexity (implementation and maintenance) is being added only to segregate functionality. Unless you’re talking about an API whose role is just to serve layer communication, she’s part of the business.

  • ok.. I get it. So the focus will be on functionality. Complexity will be a consequence of the choice of function, and it will be something inevitable.

  • @zwitterion exactly. After all, it is a design choice - maintenance will be required one way or another.

Browser other questions tagged api microservices

You are not signed in. Login or sign up in order to post.