Now that we have explored monitoring apis with Prometheus, lets take a look at monitoring our APIs with Grafana. You may have noticed from the previous blog that Prometheus is awesome, but takes some time to fully flesh out and their dashboards aren’t the best. Good thing Grafana specializes in data visualization. We will not even have to configure all our Prometheus queries, so let’s get started.
We first need to confirm everything is running, if so your output should look similar to the above image. If you are not familiar with getting everything up and running please reference our previous blog. By navigating to 127.0.0.1:3000 you should see the Grafana home page. If you are not familiar with Grafana you may be wondering where the dashboards are. They are all located in the top left dropdown where we will see 4 pre-configured dashboards. Let’s review each of them to understand what each of them does.
Docker Host Dashboard
The Docker Host Dashboard shows metrics for monitoring the usage of the server. Thanks to dockerprom(link github repo) for pre-configuring all this we can now see:
Server uptime, CPU idle percent, number of CPU cores, available memory, swap and storage.
System load average graph, running and blocked by IO processes graph, interrupts graph.
CPU usage graph by mode (guest, idle, iowait, irq, nice, softirq, steal, system, user).
Memory usage graph by distribution (used, free, buffers, cached).
IO usage graph (read Bps, read Bps and IO time).
Network usage graph by device (inbound Bps, Outbound Bps).
Swap usage and activity graphs.
Docker Containers Dashboard
The Docker Containers Dashboard shows key metrics for monitoring running containers:
Total containers CPU load, memory and storage usage.
Running containers graph, system load graph, IO usage graph.
Container CPU usage graph.
Memory usage graph.
Cached memory usage graph.
Network inbound usage graph.
Container network outbound usage graph.
Monitor Services Dashboard
The Monitor Services Dashboard shows key metrics for monitoring the containers that make up the monitoring stack:
Prometheus container uptime, monitoring stack total memory usage, Prometheus local storage memory chunks and series.
Container CPU usage graph.
Memory usage graph.
Prometheus chunks to persist and persistence urgency graphs.
Chunks ops and checkpoint duration graphs.
Samples ingested rate, target scrapes and scrape duration graphs.
We now have a fully functioning monitoring tool with no code. Isn’t that awesome? A no code API tool and a no code data visualization tool, it can’t get much better than this. This post has only scratched the surface with regards to what you can accomplish with these tools. If you are interested in this for a Ruby application, check out our friends over at Scout who wrote a blog about doing exactly that. If you like what you see, sign up for a free trial today or contact us for more information!
DreamFactory CTO Jason Gilmore recently sat down with NoSQL Database Podcast host Matt Groves to talk about DreamFactory, NoSQL database solutions, and advanced API devops topics such as performance, profiling, and logging. Here’s a chronological breakdown of the conversation:
These days it’s more true than ever that “no company is an island”. Many businesses rely on each other by exchanging information and much of that exchange is done via an API. When diving deeper into the question of developing APIs, you’ll undoubtedly encounter the question: SOAP or REST? Although REST APIs have become the most popular choice for today’s businesses, the decision isn’t always an easy one.
In this article, we’ll go over everything you need to know about SOAP and REST APIs. That way you can come to the conclusion that’s ultimately right for your situation.
What is an API?
There are a lot of definitions of the term “API” out there, and many can be confusing. An API (Application Program Interface) is a way for you to get information needed in a consistent format.
You can think of an API as like an interaction between a business and a customer, such as placing an order at a restaurant.
Customers first read the menu, then they decide what food they would like to order.
The waiter serves as the “middleman” between the customer and the business. They take the request and present it to the business in a way that’s most comprehensible and efficient.
The business reviews the request and sends back a response to the customer, such as a plate of food.
It’s important to note that in this example, the interaction is entirely predictable. When customers go to a restaurant, they can assume that they’ll be handed a menu. Then use that menu to place an order, and receive the food they ordered.
In the same way, APIs offer consistency to users who want to query a website for its data. By establishing a common set of rules for exchanging information, APIs make it easier for two parties to communicate.
A standard SOAP message consists of the following XML elements:
An Envelope element that identifies the document as a valid SOAP message
An optional Header element that specifies additional requirements for the message, such as authentication.
A Body element that contains the details of the request or response.
An optional Fault element that contains information about any errors encountered during the API request and response.
What is a REST API?
REST (Representational State Transfer) is an architectural style for APIs that relies on the HTTP protocol and JSON data format to send and receive messages. REST utilizes CRUD (Create, Retrieve, Update, and Delete) to keep API calls as simple as possible to understand. With its simplicity, developers can understand it whether they are the lead architect or a junior developer just starting.
The Pros and Cons of SOAP and REST
When comparing REST and SOAP, people often use the analogy of a postcard and an envelope. REST is like a postcard in that it’s lightweight and consumes less bandwidth (paper). Meanwhile, SOAP is like an envelope: there’s an extra overhead required on both ends to package and un-package it.
Note that the analogy isn’t perfect: unlike a postcard, the content of REST requests and responses isn’t (necessarily) insecure. Instead, REST uses the security of the underlying transport mechanism, which is usually HTTPS. On the other hand, SOAP implements its own security measure, which is known as WS-Security.
Some people believe that REST is largely a “replacement” for SOAP, due to its lower overhead and improved ease of use. According to Cloud Elements’ 2017 State of API Integration report, 83 percent of APIs now use REST, while only 15 percent continue to use SOAP. Some of these businesses primarily use REST, but continue to integrate SOAP APIs into their projects using tools such as DreamFactory’s SOAP connector.
However, the thought of SOAP being outdated isn’t quite accurate. Even as REST becomes the API style of choice for most businesses, SOAP remains a tool that is better-suited for certain use cases, mainly in large enterprises who need additional extensibility and logic features native to the protocol.
The advantages of REST include:
Flexibility: Although REST is most commonly implemented with HTTP and JSON, developers are by no means obligated to use them. Websites can send back responses using data formats including JSON, XML, HTML, or even plaintext-whatever best suits their needs.
Speed: Because it tends to use much less overhead, REST APIs are typically significantly faster than SOAP. While the differences might be imperceptible for a single request, the disparity grows larger and larger as you place more and more requests.
Popularity: REST has reached critical mass on the Internet. Major websites such as Google, Twitter, and YouTube all use REST APIs for users to send and receive messages. Due to this familiarity, it’s typically easier for developers to get up and running with REST.
Scalability: Thanks to their speed and simplicity, REST APIs usually perform very well at scale.
Despite the major benefits of using REST, SOAP remains the preferred protocol in certain use cases. Some organizations find that SOAP offers the transactional reliability that they’re looking for, while others simply continue to use SOAP because they need legacy system support.
The advantages of SOAP include:
Formality: SOAP can use WSDL (Web Services Description Language) to enforce the use of formal contracts between the user and the website. SOAP is also inherently compliant with ACID database standards, which ensures that the transactions it performs will be valid even in the event of errors or hardware issues.
Logic: If a REST API request is unsuccessful, it can only be addressed by retrying until the request successfully goes through. On the other hand, SOAP includes built-in successful/retry logic so that the requesting system knows how to behave.
Security: SOAP comes with its own security mechanism, WS-Security, built into the protocol. If you want to ensure that your messages are secure, rather than relying on the underlying transport mechanism as does REST, then SOAP may be the right choice.
Extensibility: In addition to WS-Security, SOAP includes support for other protocols such as WS-Addressing and WS-ReliableMessaging that can define other standards of communication and information exchange.
Converting SOAP to REST
DreamFactory can convert your SOAP service to REST in minutes. If you have your SOAP service RESTified you can take advantage of the features DreamFactory provides. Like turning security up 10 notches by securing the API with API Keys and Roles to only allow access to people that have the right to it. Even add custom events and business logic by way of our powerful Scripting engine.
For most cases, REST should be considered the “default” option as adoption continues to grow across the web. Most public-facing APIs now use REST, because it consumes less bandwidth and its compatibility with HTTP makes it easier for web browsers to use.
However, you may find that the additional features and security offered by SOAP are enough to sway your decision. In the end, the “right” choice between SOAP and REST will be highly dependent on your own situation.
Even better, the choice of SOAP and REST doesn’t have to be between one and the other. If you want to communicate with REST but still need access to legacy SOAP services, DreamFactory offers the ability to add a REST API onto any database or SOAP API.
See how quick and easy it is!
If you have your SOAP service RESTified we can take advantage of the features DreamFactory provides. Like turning security up 10 notches by securing the API with API Keys and Roles to only allow access to people that have the right to it. Even add custom events and business logic by way of our powerful Scripting engine.
If you know REST APIs are the best for you, don’t waste any more time building them. Try it yourself with your own instance of DreamFactory or connect with an API specialist today!