Coffee break #31. 9 career mistakes every developer should avoid. Why is REST API architecture gaining popularity?

9 Career Mistakes Every Software Developer Should Avoid

Source: Infoworld Let's be honest. Some of you started learning programming because you or your parents thought it would be easier for you to make a lot of money. You weren't really into computers in school, and you didn't really enjoy software development. If this is true, then this means that you will always be a mediocre programmer. Yes, you will earn good money because our industry favors it, but this article is not for you. But if you were punished as a child for taking apart electronics to figure out how they worked... If you spent half the night on the Internet to learn how to create a video game... If you spent precious free time learning about what no one asked you... this article is for you. You need to change the perception of your career. You no longer write code for fun: you do it for money. For fun, you can support your personal projects. But please make sure you at least enjoy your day job. If not, find a better place if possible. Your goal should be to open your retirement fund, put all your after-tax dollars into it, buy a house, a car, and do what you want. Maybe travel. At the same time, you need to think about your career, not just your current job. To do this, you need to avoid nine pitfalls, which we will now discuss.

Pitfall #1: Don't stay in one technology for too long

I understand. Do you like C# or Java or JavaScript, Python or Cobol. But most technologies have a life cycle of adoption, peak, outsourcing, niche, and obsolescence. I mean, if you knew Cobol in the 1980s, it would have been cool. But Cobol programmers don't make much money these days. That is, the point is that knowing only one programming language, sooner or later you will have to cut your expenses, move to a cheaper city, because you will earn less.

Pitfall No. 2: don’t be an IT monopolist

You need to hedge your investments. It may seem like you just need to become an expert in the technologies that currently dominate the market. But then you will face a lot of competition. Additionally, when demand for your specialty declines, you should already have an exit plan in place. For example, I was a C++ geek when Java came out. I learned Java. A few years ago, everyone started talking about Ruby as the new rising star among programming languages. And at some point it seemed that Perl would reach the same level as Java. Predicting the future is difficult, so hedging your bets is the safest way to ensure relevance in the job market.

Pitfall #3: Don't hold on to fads

Sooner or later the magic disappears. People won't hire Groovy or Ruby developers. If your boss allows you to use legacy languages ​​on a project, it will either be because he doesn't care or is simply ignorant. By all means, learn and use the latest technology. Be prepared to be one of the first to know about them and become an expert in it. On the other hand, also be prepared to make drastic changes if demand for your specialty declines. There are always other new technologies to fall in love with, be it a language or a database.

Pitfall #4: Allergy to rules

Every organization, no matter how big or small, has its own office rules. You will have to study them and follow them. Otherwise, you will become a pawn in someone else's game or find yourself isolated on the team. If you are interested in a career and productive relationships at work, learn to follow defensive tactics in office rules.

Pitfall #5: disinterest in business

"I'm just a developer, I'm not interested in business." This is a road to nowhere. You need to learn to count. Is your company doing well? What are its main business objectives? What are her most important projects? How does technology or software help achieve them? How does your company fit into the overall industry? If you don't know the answers to these questions, you'll end up working on unimportant projects for unimportant people at unimportant companies for a relatively insignificant amount of money.

Pitfall No. 6: the mentality of “trade union solidarity”

When I was young, one of my colleagues was a man who planned almost everything six months in advance. He made the mistake of going on vacation, so I finished the entire project in two weeks, but left him one piece to work on. I expected him to be happy about it. It turned out that he was not happy. It all ended with him using every opportunity to get me fired. This became his main goal. He even complained about me to our new director. Of course I did all my work. I was an innovator. I was always finding new ways to do things better and faster and solve problems. He retired shortly after I left for another job. Several times I saw him in a cafe, and we pretended that we didn’t know each other. This wouldn't be the last time I encountered this type of work: "Do things slowly or things will get worse." My advice: write correct code, but be prepared for the unexpected. If the problem cannot be solved, leave slamming the door: your company is not the only one on the market.

Pitfall No. 7: you don’t know your worth

"I'm not here for the money." Well then, take up a hobby. Don't go to work every day thinking about your next paycheck. You also shouldn't go to work if you earn 50% less than everyone else. Know your worth and don't underestimate it.

Pitfall #8: Treating your job like a job

"It's just a job." No, this is a step in your career. You won't be in this job forever. So what can you learn here? What will be your next step? Where do you ultimately want to end up? How will this work help you get to that goal? Increase your awareness of your surroundings. This will serve you well in the long run. It's not just a job, it's a journey.

Pitfall No. 9: You think it's only about money

Salespeople like to say, “I work if you flip a coin.” Yes, but unless you work in sales, then no one wants to work with someone who is in that job just for the money. I know that I only want to work with someone who is responsible for their work. And you? On the other hand, there is no need to be unbearably responsible. If all you're really worried about is the eternal debate of tabs or gaps, you might need to take a sedative.

Why is REST API architecture gaining popularity?

Source: DZone Instant communication is an amazing thing. We are all accustomed to the fact that we can instantly communicate with anywhere in the world. From desktop computers or mobile devices, we can buy, post, attach and select anything, anywhere. We are connected to each other and to the world like never before. But how does this happen? How does data get to us “from there”? Devices and applications communicate with each other using an application programming interface, or API. This is exactly the engine “under the hood”. It's always behind the scenes, and we tend to think of it as something ordinary, but it's the API that creates all the interactivity we count on.

What is an API?

Simply put, an API is a messenger that accepts requests, tells the system what you want to do, and then returns a response to you. For a visual example, imagine the API as a waiter in a restaurant. Imagine that you are sitting at a table, holding a menu in your hands, and the kitchen is part of the system that will prepare your order. The API is the link that will transmit your order to the kitchen and deliver the food to the table.

Let's take a real example:

We are all familiar with the process of searching for flights online and know that in order to book a flight we will have to interact with the airline's website. You access their database to see if seats are available on a specific date and what costs you can expect based on your flight requirements. But what if you don't use an airline website that has direct access to information? What if you use an online booking service that collects information from different airlines? The service interacts with the airline's API, where the API is the interface that, like our helpful waiter, requests information from the online service about seat reservations and the passenger's choice of meal or baggage preferences. The API then takes the airline's response and delivers it back to the online service, which displays the information to the passenger. Much the same process occurs between all other applications, data, and devices. They all have APIs that allow computers to control them, and this ultimately creates communication.

What types of APIs are there?

API architecture can be implemented in two main ways: one of these ways of implementing information transfer is SOAP, and the other main way is REST. We've already established that APIs provide communication between two applications. Now we will learn how exactly SOAP and REST fit into the communication architecture.

SOAP API

SOAP (Simple Object Access Protocol) is a web service that follows specifications with certain communication principles that are established between a central body called W3C and a core set of specifications. This set includes:

• SOAP
• WSDL
• UDDI

SOAP is a protocol that defines how two applications will communicate with each other. Two applications must follow a common format when communicating with each other, and this common format must be based on the XML language. The XML in SOAP APIs must conform to the SOAP Message standard, which consists of Envelop, Header, and Body.

REST API

This is a very important but often misunderstood concept of web services, so let's decipher what REST or RESTful API means. REST is a web service that initiates communication between two applications using its own architecture principles. REST architecture is an architectural style that does not follow any protocol, there are no strict specifications, and there is no central authority that controls the specifications. This makes REST versatile for using or creating any kind of service. When these principles are applied when creating a web service, we get a RESTful web service. Now let's go a little deeper and find out the principles on which REST architecture is based.

Unified Interface

In a RESTful architecture, everything can be considered a resource. For example, if you are trying to create an application for an employee management system. This application can be developed using any language, on any platform and for any platform. Likewise, any database can be used to handle internal services. The concept of resources in REST API implies that the user can define any information or any module as a resource. Given an employee management system, the creator can define the employee resource, departments, and any other module used in the application.

Stateless

In a RESTful architecture, all responses and requests, and all communication between servers, are stateless. This means that the server does not maintain the current state of the system, the client may send a request that itself completes. And this request does not depend on any of the previous requests. For example, if you are shopping online and adding items to your cart, the server will not maintain the state of your cart, so every time a user submits a request to the server, it will contain the state of the cart at the time the request was made. When stateless, there is no overhead for the server to store or maintain the session, hence it improves the performance of the web service.

Caching capability

In the last protocol, we noticed that in RESTful architecture the server does not save session state, all caching happens on the client side. Whenever a client sends a request to the server, the server returns a response that contains the actual data as well as other metadata that tells the client whether it should store the response locally or not.

Multi-level system

REST principles state that whenever there is communication between a client and a server, there can be multiple layers between them, and these layers can be used to implement multiple purposes such as message translation, performance enhancement, caching, and a variety of other things. Each level of communication has a specific task. With multiple layers of communication, the system operates efficiently, improving speed and durability.

Code on request

This is an optional limitation of RESTful web services that works when the user submits a request to receive a response. The response can run client-side code. This principle expands the functionality of communication.

Why are REST APIs being used more and more often?

REST is for the most part easier to use, more flexible, and has a number of advantages over SOAP. For example, you don't need expensive tools to interact with any web service. REST architecture is simpler, can be easily customized, and does not require special skills when creating a communication model. It is efficient to use because it can use the client side of the server to store client-related information. REST uses smaller message formats and provides faster interactions because it does not require time-consuming processing. REST is also closer to other web technologies when it comes to design philosophy.

SOAP or REST?

For the requirements of a typical web application, SOAP is often overkill. REST is a simpler solution that has everything you need when a web application needs an API. However, there are times when the API needs to be a little more complex to accomplish tasks. For example, if an API is required for automated requests, a SOAP API would be a better choice for that scenario. Simply put, choose SOAP if the problem is large and complex, and choose REST if you need a simple solution.