By nature, APIs are meant to be used. Even if all of your users are internal, security problems can still arise. To help with this, we've assembled a list of best practices to keep in mind when securing and locking-down an API or web service.
The ecosystem around making requests in Node.js applications is huge. With countless libraries available, it can be helpful to understand why they exist. This helps to improve your understanding of Node.js as a whole, and makes choosing an HTTP client easier. In the first post in this series, we looked at creating servers using Node's http module. In this post, we will explore making a request using the http.request method and handling the response.
Using Node.js on the web generally involves a server framework, like Express, Hapi, or Koa. These make working with the underlying HTTP support easier. Sometimes you need the full power of a framework, but in other cases that can be overkill. In this article, we'll ignore the benefits of a framework and look at the underlying features of Node's HTTP module and how you can use it to create a web server. In future articles, we'll examine other features of the HTTP module.
When it comes to monitoring third-party APIs and web services, what you monitor is as important as how you monitor. Data is useful, but actionable data is where the true value is. Below we've listed the most common and valuable metrics to monitor when relying on third-party API integrations and web services.
When you interact with a REST API, are you making calls directly or are you using a client from the API provider? Many APIs now provide clients, wrappers, or SDKs. These terms all mean the same thing in this context. What happens if the API you are using doesn't offer a client? Do you even need one? Is there any benefit? In this article, we will explore some of the reasons you may want to build one.
GraphQL is a query language for APIs and a set of tools that enable sending and processing queries. While originally developed at Facebook, it has since grown beyond the social network's specific use case. Essentially, the client describes the type of data they want, and the server delivers only that data. At Bearer, we use GraphQL internally to drive our dashboard.
When working with APIs you may come across the term REST or RESTful. REST stands for Representational State Transfer. In essence, REST is a set of recommendations that an API can adhere to. This makes designing the API easier and using the API more predictable.
API has become one of those catch-all terms that developers throw around without really considering the context. On any given week, you will come across discussions like "How to use the Twitter API", "New framework X is great because it has a low API surface", and "Best practices for building an API." Is an API a data source? Is it a service? Is it a way to call native functionality? The truth is, in modern software development it can mean any of these things.
Your application is running smoothly. Tests have passed. Suddenly you start to see 429 error responses from an API. As the name implies, you have made too many requests and your application has been rate limited. The 429 (Too Many Requests) error is an HTTP status code that often occurs when you've hit a request limitation of an API.
Out of the box, Node.js offers the http library for making requests, but it isn't particularly user friendly and requires some customization before it can be easily used. As a result, a large ecosystem of third-party libraries have emerged to make AJAX and HTTP requests easier. Some offer cross-platform (browser and Node.js) support, while others focus on bundle size or developer experience. With some many options, how do you choose?
