JavaRush /Blog Java /Random-ES /Pausa para el café #31. 9 errores profesionales que todo ...

Pausa para el café #31. 9 errores profesionales que todo desarrollador debería evitar. ¿Por qué la arquitectura API REST está ganando popularidad?

Publicado en el grupo Random-ES

9 errores profesionales que todo desarrollador de software debe evitar

Fuente: Infoworld Pausa para el café #31.  9 errores profesionales que todo desarrollador debería evitar.  ¿Por qué la arquitectura API REST está ganando popularidad?  - 1 Seamos honestos. Algunos de ustedes comenzaron a aprender programación porque ustedes o sus padres pensaron que les sería más fácil ganar mucho dinero. En la escuela no te gustaban mucho las computadoras y no disfrutabas mucho el desarrollo de software. Si esto es cierto, entonces significa que siempre serás un programador mediocre. Sí, ganarás un buen dinero porque nuestra industria lo favorece, pero este artículo no es para ti. Pero si de niño te castigaran por desarmar aparatos electrónicos para descubrir cómo funcionan... Si pasaras media noche en Internet para aprender a crear un videojuego... Si pasaras un valioso tiempo libre aprendiendo sobre qué nadie te preguntó... este artículo es para ti. Necesitas cambiar la percepción de tu carrera. Ya no escribes código por diversión: lo haces por dinero. Por diversión, puedes apoyar tus proyectos personales. Pero asegúrese de al menos disfrutar de su trabajo diario. Si no, busque un lugar mejor si es posible. Su objetivo debe ser abrir su fondo de jubilación, poner en él todo su dinero después de impuestos, comprar una casa, un automóvil y hacer lo que quiera. Quizás viajar. Al mismo tiempo, debes pensar en tu carrera, no sólo en tu trabajo actual. Para hacer esto, debe evitar nueve trampas, que ahora discutiremos.

Error #1: No permanecer en una tecnología por mucho tiempo

Entiendo. ¿Te gusta C# o Java o JavaScript, Python o Cobol? Pero la mayoría de las tecnologías tienen un ciclo de vida de adopción, pico, subcontratación, nicho y obsolescencia. Quiero decir, si conocieras Cobol en la década de 1980, habría sido genial. Pero los programadores de Cobol no ganan mucho dinero hoy en día. Es decir, la cuestión es que sabiendo solo un lenguaje de programación, tarde o temprano tendrás que recortar gastos, mudarte a una ciudad más barata, porque ganarás menos.

Error número 2: no sea un monopolista de TI

Necesita cubrir sus inversiones. Puede parecer que sólo necesitas convertirte en un experto en las tecnologías que actualmente dominan el mercado. Pero luego te enfrentarás a mucha competencia. Además, cuando la demanda de su especialidad disminuye, ya debería contar con un plan de salida. Por ejemplo, yo era un experto en C++ cuando apareció Java. Aprendí Java. Hace unos años, todo el mundo empezó a hablar de Ruby como la nueva estrella en ascenso entre los lenguajes de programación. Y en algún momento parecía que Perl alcanzaría el mismo nivel que Java. Predecir el futuro es difícil, por lo que cubrir sus apuestas es la forma más segura de garantizar la relevancia en el mercado laboral.

Error #3: No te aferres a las modas pasajeras

Tarde o temprano la magia desaparece. La gente no contratará desarrolladores de Groovy o Ruby. Si tu jefe te permite usar lenguajes heredados en un proyecto, será porque no le importa o simplemente es un ignorante. Por supuesto, aprenda y utilice la última tecnología. Prepárate para ser uno de los primeros en conocerlos y convertirte en un experto en ello. Por otro lado, también esté preparado para realizar cambios drásticos si disminuye la demanda de su especialidad. Siempre hay otras tecnologías nuevas de las que enamorarse, ya sea un lenguaje o una base de datos.

Error #4: Alergia a las reglas

Cada organización, sin importar cuán grande o pequeña sea, tiene sus propias reglas de oficina. Tendrás que estudiarlos y seguirlos. De lo contrario, te convertirás en un peón en el juego de otra persona o te encontrarás aislado en el equipo. Si está interesado en una carrera y en relaciones productivas en el trabajo, aprenda a seguir tácticas defensivas en las reglas de la oficina.

Error #5: desinterés en los negocios

"Solo soy un desarrollador, no me interesan los negocios". Este es un camino a ninguna parte. Necesitas aprender a contar. ¿Le va bien a su empresa? ¿Cuáles son sus principales objetivos comerciales? ¿Cuáles son sus proyectos más importantes? ¿Cómo ayuda la tecnología o el software a lograrlos? ¿Cómo encaja su empresa en la industria en general? Si no sabe las respuestas a estas preguntas, terminará trabajando en proyectos sin importancia para personas sin importancia en empresas sin importancia por una cantidad de dinero relativamente insignificante.

Escollo nº 6: la mentalidad de “solidaridad sindical”

Cuando yo era joven, uno de mis compañeros era un hombre que planificaba casi todo con seis meses de antelación. Cometió el error de irse de vacaciones, así que terminé todo el proyecto en dos semanas, pero le dejé una pieza para trabajar. Esperaba que estuviera feliz por eso. Resultó que no estaba contento. Todo terminó cuando él aprovechó cada oportunidad para que me despidieran. Este se convirtió en su principal objetivo. Incluso se quejó de mí con nuestro nuevo director. Por supuesto que hice todo mi trabajo. Yo era un innovador. Siempre estaba encontrando nuevas formas de hacer las cosas mejor y más rápido y resolver problemas. Se jubiló poco después de que yo me fuera a buscar otro trabajo. Lo vi varias veces en un café y fingimos que no nos conocíamos. Esta no sería la última vez que me encontré con este tipo de trabajo: "Haz las cosas lentamente o las cosas empeorarán." Mi consejo: escribe el código correcto, pero prepárate para lo inesperado. Si el problema no se puede solucionar, deja de dar un portazo: tu empresa no es la única en el mercado.

Error número 7: no sabes lo que vales

"No estoy aquí por el dinero". Bueno, entonces busca un hobby. No vayas a trabajar todos los días pensando en tu próximo sueldo. Tampoco deberías ir a trabajar si ganas un 50% menos que los demás. Conoce tu valor y no lo subestimes.

Error #8: Tratar tu trabajo como un trabajo

"Es sólo un trabajo". No, este es un paso en tu carrera. No estarás en este trabajo para siempre. Entonces, ¿qué puedes aprender aquí? ¿Cuál será tu próximo paso? ¿Dónde quieres terminar en última instancia? ¿Cómo le ayudará este trabajo a alcanzar ese objetivo? Aumenta tu conciencia de tu entorno. Esto le será de gran utilidad a largo plazo. No es sólo un trabajo, es un viaje.

Error número 9: crees que solo se trata de dinero

A los vendedores les gusta decir: "Trabajo si lanzas una moneda". Sí, pero a menos que trabajes en ventas, nadie quiere trabajar con alguien que hace ese trabajo sólo por el dinero. Sé que sólo quiero trabajar con alguien que sea responsable de su trabajo. ¿Y tú? Por otro lado, no hay necesidad de ser insoportablemente responsable. Si lo único que realmente te preocupa es el eterno debate entre pestañas y espacios, es posible que necesites tomar un sedante.

¿Por qué la arquitectura API REST está ganando popularidad?

Fuente: DZone La comunicación instantánea es algo asombroso. Todos estamos acostumbrados a poder comunicarnos instantáneamente con cualquier parte del mundo. Desde computadoras de escritorio o dispositivos móviles, podemos comprar, publicar, adjuntar y seleccionar cualquier cosa, en cualquier lugar. Estamos conectados entre nosotros y con el mundo como nunca antes. Pero, ¿cómo sucede esto? ¿Cómo nos llegan los datos “desde allí”? Pausa para el café #31.  9 errores profesionales que todo desarrollador debería evitar.  ¿Por qué la arquitectura API REST está ganando popularidad?  - 2Los dispositivos y aplicaciones se comunican entre sí mediante una interfaz de programación de aplicaciones o API. Este es exactamente el motor "debajo del capó". Siempre está detrás de escena y tendemos a pensar en ello como algo común y corriente, pero es la API la que crea toda la interactividad con la que contamos.

¿Qué es una API?

En pocas palabras, una API es un mensajero que acepta solicitudes, le dice al sistema lo que desea hacer y luego le devuelve una respuesta. Para ver un ejemplo visual, imagine la API como un camarero en un restaurante. Imagina que estás sentado en una mesa, sosteniendo un menú en tus manos y la cocina es parte del sistema que preparará tu pedido. La API es el enlace que transmitirá tu pedido a la cocina y entregará la comida en la mesa.

Pongamos un ejemplo real:

Todos conocemos el proceso de búsqueda de vuelos online y sabemos que para poder reservar un vuelo tendremos que interactuar con el sitio web de la aerolínea. Accede a su base de datos para ver si hay asientos disponibles en una fecha específica y qué costos puede esperar según los requisitos de su vuelo. Pero, ¿qué pasa si no utiliza el sitio web de una aerolínea que tenga acceso directo a la información? ¿Qué pasa si utiliza un servicio de reservas en línea que recopila información de diferentes aerolíneas? El servicio interactúa con la API de la aerolínea, donde la API es la interfaz que, al igual que nuestro servicial camarero, solicita información del servicio en línea sobre las reservas de asientos y las preferencias de comida o equipaje del pasajero. Luego, la API toma la respuesta de la aerolínea y la devuelve al servicio en línea, que muestra la información al pasajero. El mismo proceso ocurre entre todas las demás aplicaciones, datos y dispositivos. Todos tienen API que permiten que las computadoras los controlen y, en última instancia, esto crea comunicación.

¿Qué tipos de API existen?

La arquitectura API se puede implementar de dos formas principales: una de estas formas de implementar la transferencia de información es SOAP y la otra forma principal es REST. Ya hemos establecido que las API proporcionan comunicación entre dos aplicaciones. Ahora aprenderemos cómo encajan exactamente SOAP y REST en la arquitectura de comunicación.

API de jabón

SOAP (Protocolo simple de acceso a objetos) es un servicio web que sigue especificaciones con ciertos principios de comunicación que se establecen entre un organismo central llamado W3C y un conjunto central de especificaciones. Este conjunto incluye:
  • JABÓN
  • WSDL
  • UDDI
SOAP es un protocolo que define cómo dos aplicaciones se comunicarán entre sí. Dos aplicaciones deben seguir un formato común cuando se comunican entre sí, y este formato común debe basarse en el lenguaje XML. El XML en las API SOAP debe cumplir con el estándar de mensajes SOAP, que consta de sobre, encabezado y cuerpo.

API DESCANSO

Este es un concepto de servicios web muy importante pero a menudo mal entendido, así que descifremos qué significa REST o RESTful API. REST es un servicio web que inicia la comunicación entre dos aplicaciones utilizando sus propios principios de arquitectura. La arquitectura REST es un estilo arquitectónico que no sigue ningún protocolo, no existen especificaciones estrictas y no existe una autoridad central que controle las especificaciones. Esto hace que REST sea versátil para usar o crear cualquier tipo de servicio. Cuando se aplican estos principios al crear un servicio web, obtenemos un servicio web RESTful. Ahora profundicemos un poco más y descubramos los principios en los que se basa la arquitectura REST.

Interfaz unificada

En una arquitectura RESTful, todo puede considerarse un recurso. Por ejemplo, si está intentando crear una aplicación para un sistema de gestión de empleados. Esta aplicación se puede desarrollar utilizando cualquier idioma, en cualquier plataforma y para cualquier plataforma. Asimismo, cualquier base de datos puede utilizarse para manejar servicios internos. El concepto de recursos en REST API implica que el usuario puede definir cualquier información o cualquier módulo como recurso. Dado un sistema de gestión de empleados, el creador puede definir los recursos de los empleados, los departamentos y cualquier otro módulo utilizado en la aplicación.

Apátrida

En una arquitectura RESTful, todas las respuestas y solicitudes, y toda la comunicación entre servidores, no tienen estado. Esto significa que el servidor no mantiene el estado actual del sistema, el cliente puede enviar una solicitud que él mismo completa. Y esta solicitud no depende de ninguna de las solicitudes anteriores. Por ejemplo, si está comprando en línea y agregando artículos a su carrito, el servidor no mantendrá el estado de su carrito, por lo que cada vez que un usuario envíe una solicitud al servidor, contendrá el estado del carrito en el momento en que se realizó la compra. se hizo la solicitud. Cuando no tiene estado, el servidor no tiene que almacenar o mantener la sesión, por lo que mejora el rendimiento del servicio web.

Capacidad de almacenamiento en caché

En el último protocolo, notamos que en la arquitectura RESTful el servidor no guarda el estado de la sesión, todo el almacenamiento en caché ocurre en el lado del cliente. Cada vez que un cliente envía una solicitud al servidor, el servidor devuelve una respuesta que contiene los datos reales, así como otros metadatos que le indican al cliente si debe almacenar la respuesta localmente o no.

Sistema multinivel

Los principios REST establecen que siempre que hay comunicación entre un cliente y un servidor, puede haber múltiples capas entre ellos, y estas capas se pueden usar para implementar múltiples propósitos, como traducción de mensajes, mejora del rendimiento, almacenamiento en caché y una variedad de otras cosas. Cada nivel de comunicación tiene una tarea específica. Con múltiples capas de comunicación, el sistema funciona de manera eficiente, mejorando la velocidad y la durabilidad.

Código bajo petición

Esta es una limitación opcional de los servicios web RESTful que funciona cuando el usuario envía una solicitud para recibir una respuesta. La respuesta puede ejecutar código del lado del cliente. Este principio amplía la funcionalidad de la comunicación.

¿Por qué las API REST se utilizan cada vez con más frecuencia?

REST es en su mayor parte más fácil de usar, más flexible y tiene una serie de ventajas sobre SOAP. Por ejemplo, no necesita herramientas costosas para interactuar con ningún servicio web. La arquitectura REST es más simple, se puede personalizar fácilmente y no requiere habilidades especiales al crear un modelo de comunicación. Es eficiente de usar porque puede usar el lado cliente del servidor para almacenar información relacionada con el cliente. REST utiliza formatos de mensajes más pequeños y proporciona interacciones más rápidas porque no requiere un procesamiento que requiere mucho tiempo. REST también está más cerca de otras tecnologías web en lo que respecta a la filosofía de diseño.

¿JABÓN o DESCANSO?

Para los requisitos de una aplicación web típica, SOAP suele ser excesivo. REST es una solución más sencilla que tiene todo lo necesario cuando una aplicación web necesita una API. Sin embargo, hay ocasiones en las que la API necesita ser un poco más compleja para realizar las tareas. Por ejemplo, si se requiere una API para solicitudes automatizadas, una API SOAP sería una mejor opción para ese escenario. En pocas palabras, elija SOAP si el problema es grande y complejo, y elija REST si necesita una solución simple.
Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION