How can you design a flexible Web API for future changes?

Recuerde que sus usuarios son a veces parte de su organización y a veces están fuera de ella. A veces los pedidos vienen desde el front-end a veces es un servicio B2B, a veces es interconeción entre sistempas propios o microservicios. Recordar también que testers, operadores y administradores pueden utilizar las API directamente (por ejemplo con Postman). Sus usuarios pueden necesitar usar el sistema (y la API) desde sus inicios, aún cuando no esté en etapas tempranas de pre producción, testing o de uso exclusivo para usuarios invitados.

First of we would need to know how scalable the app will need to be. Try to understand the target audience and try to gage what their future needs or how the app may evolve over time.

As mentioned above. Swagger is a great tool for testing and documenting your API. There is not much more I can say other than it makes your workflow run much more smoothly. I may also recommend Postman but that has it's own particular advantages and disadvantages.

To test your API locally I would suggest first starting with Postman. It's probably the best tool for the job but when it comes to running and testing an API in real time by many different people located in different parts of the world such as a remote team. I would suggest Swagger. Updates that are pushed can be tested quickly and easily by everyone in real time which gives you a better feel for real world situations.

Feedback for you API would primarily come from the feedback you get from the beta testers of your app. It would therefore be your job to figure out if the problems reported are API based or frontend based which is why it is very important to define frontend and backend capabilities with distinct parameters so that when it comes time for debugging we know exactly where the issue comes from. For example a pagination issue that may arise can either be frontend or backend related depending on where the bulk of the implementation is dealt with. In cases where pagination is handled by the backend as in the case of MongoDB then we could quickly and easily fix the issue.

I would also take into consideration the level of computation that the application is going to require, the estimated user growth and possible addons to the application when designing your API. In some cases budget may be an issue and there you may have to share the workload between the frontend and the Backend.

Es fundamental mantener la compatibiliad hacia atrás por un lado y la coherencia de la interface por el otro. Una idea es no ser demasiado compacto o estrecho en el dise?o de la carga (payload) recibida o devuelta. Por ejemplo si hay un "endpoint" en la API que recibe una lista de algo y queremos permitir especificar qué columnas va a recibir y la longitud máxima de cada una lo que hay que tratar de evitar es pedir un JSON del tipo '{columna1: 23, colunma2: 100}' porque si después se quiere poder especificar también el tipo de empaque habrá que agregar otra lista como esa, parece más razonable pedir desde el principo algo más explícito como `{columna1:{ancho: 23}, columna2: {ancho: 100}}` eso hace más fácil el agregado una característica