REST API vs. SOAP Web Services Management

Let’s take a step back and look at the rise of microservices and REST and the apparent decline of SOAP-based web services. What are the statistics and the reasons?

Back in the day, web services were the de facto standard for accessing “systems of record.” SOAP web services’ popularity grew because of an option to share data, access from any system, and security options. This type of architecture grew out to be synonymous with enterprise architecture.

More and more, projects are utilizing API management in those architectures now and pushing on web services’ door.

The Web Services Legacy

Web Services is a vast array of reasonably well-defined XML-based, transport agnostic, definitions that allow data communication between parties. The protocols and definitions cover everything from the message content to the meta-data and systems surrounding the content e.g. security or notifications of changes.

That definition misses as much as it says.

XML is a hard thing for human beings to read. The Ws standards can be bloated. The tooling around the standards can be poor, given the complexity of the standards. The definitions themselves are sometimes loose, and thus interoperability (one of the main reasons originally cited for using web services) is not as good as it could be.

That aside, web services have been tremendously successful in what they are good at — interoperability of large enterprise systems. These enterprises liked the idea that web services made them vendor neutral (in theory). They also liked that having standards means cheaper developers — when something is standard, it can be learned by more people. In addition, there was an implementation arms race amongst the application server vendors, who just loved selling their latest and greatest server. This was an all-around win-win.

REST vs Web Services

We can see that REST is gaining more and more popularity, while web services are loosing popularity each day.

The Case for Restful API Management

I believe that there are three things making the case for RESTful API Management and challenging web services’ domination — and they are not all technical.

Changing Demands

The world is getting faster and faster. Consumers are demanding more and more real-time information, sometimes from places where it was never being exposed before. Direct interaction with data, and just the data, in a simple way, is being demanded by the new world order.

As this data demand has increased, companies are exposing their data-sets in order to encourage the use of it by third parties. Often this exposing of data is done only to enable the third parties and may not have a direct impact on their own bottom-line. This has been coined the “API Economy.”

Decreasing Time-To-Market and Complexity Hiding

  • Time-to-market: Over the past few years, digital disruption has increased. Each company wants to start selling its products as fast as possible. Therefore, when building APIs, Reducing Time-To-Market is much more important.
  • Sales growth for select Internet retailers: Time-to-market is more valuable than ever before as companies strive to keep up with their fresh competitors. It’s not just the old pre-Internet companies that are struggling to keep up. There is data to show that even the early internet giants are also being overtaken by new start-ups who are leveraging the social media age to their advantage.
  • Complexity hiding: If you’re a computer science grad, it would have been drummed into you on day one that you hide away complexity as much as possible when you are writing code. Yet, we didn’t do that when it came to system configuration and administration. This is mainly because software, and technology in general, has moved on so fast that user interfaces and tooling was secondary to getting the function out of the door.

With the advent of the mobile age, users are expecting those same rich user interfaces in everything they do.

Making APIs easier to implement, secure, and manage reduces skills requirements and speeds time-to-market.

Changing Clients

The third reason web services are not today’s technology of choice is because mobile devices and clients with rich user interfaces are the modern way. This is complementary to hiding the complexity on the server-side. These applications are being written by developers who want to focus on the user interfaces and don’t want to learn the other deeply-technical data handling skills. How they access the data is almost secondary and their skills are not in that area. They just want access to data, as and when they need it and in a simple manner.

Micro Services and Agile Development

The business needs highlighted above are having further ramifications in the project delivery.

Micro Services Popularity

Microservices’ popularity are rising.

With the promises that they hold ‘just when you need it’ access to data and services, microservices are challenging the traditional SOA architectures’ hold on the enterprise. They fit well into the API management ease-of-use paradigm.

Micro-services are still in their ascendancy, and tooling and architectures are still being invented. Even so, they are already challenging web services with their promises to deliver just the right amount of access to the systems. This also fits nicely into the agile methodologies being employed by most businesses today. Small sprints and piecemeal construction techniques require “just enough” work to be done to get from A to B.

We can see the ramifications of Agile and API tooling today — around 75% of API management projects are internally focused. This tells us that APIs are not just about directly making money by selling data, but that they are being seen as today’s best-practice.

Hypothesised use of Web Services Vs APIs

I’m convinced that we will see fewer and fewer web services used internally and externally, but they aren’t dead just yet. I expect standards to play a bigger part in API management but its emphasis on simplicity and complexity hiding will stop standards being API’s death knell.

I also believe that same simplicity push will have ramifications for lots of other software products when customers realize that enterprise software doesn’t always have to be so hard. Please check theRESTful APIs Predictions post for further reading.

I’ve shown how web services grew out of a world that was demanding standards. This enabled web services and its associated architectures to dominate the market by enabling a generic software workforce and cross-vendor interoperability.

API management is being born into an ever-speeding, real-time world. Rich user interfaces are being written by developers with the interface in mind more than the data. This is driving simpler tools, integration architectures, and techniques.

This, as they say, is the perfect storm. Where once a web service would be created with all of its complexity, there will now be APIs with all their simplicity and developer-led tooling, speeding time-to-market.

I strongly believe that the tools that simplify the creation, testing, and configuration of REST APIs are at the forefront of a trend to the simplification of other products — but that’s for another day!

 

Fuente: REST API vs. SOAP Web Services Management – DZone Integration

Relational vs. NoSQL Databases for API Traffic 

API Consumption drives the importance of API Traffic. Without insight into how your APIs are being consumed, you’re unable to get the analytics for your customers and API usage.

API-traffic-blog-banner.png

API traffic data has a few characteristics; high frequency, payload sizes, data structure, tables, volume, and objects. Persisting API traffic is important because most services have some sort of rate-limiting and different billing tiers for customers based on their usage. There is usually a threshold for alerting and scaling, so if someone is using more API calls than they should, you can partition them. You also want to be able to provide analytics to your internal organization for the different APIs/resources you are exposing. If your customers are exposing an API, it is a good bet that they are integrating with other services as well, allowing them to slice and dice their data with the data they are consuming from your product.

There are differences in typical API request payloads and response payloads. The request data vs. response data can change what your persistent strategy needs to be. With request payloads, you usually have moderate-to-large payload sizes. About 80% of API requests are GET requests, and POST requests can also be large. The response payloads are also typically large in size. The data structures are indeterministic, meaning when you are trying to run analytics on the data the table can be large and slicing and dicing the data responses can be variable.

Slack_for_iOS_Upload-3.jpg

Establishing that persisting the data is the best option, most will look to some SQL database, considering that they are most likely already using one. The question is whether a NoSQL database should be considered. SQL, being more than 40 years old, is the primary interface for RDMBS and, having commercial and open-source implementations, it is a strong consideration.

NoSQL, on the other hand, has existed since the 1960s and was the primary storage mechanism before SQL gained popularity. It has gained more traction in last 10 years.

With the comparison of the two technologies below, the main factors in the decision-making process are data growth, online versus archived data, search filter flexibility, search performance, and clustering and sharding. When deciding what the best is for you, consider the measure of your current inbound API traffic, the data-retention policy, estimated data growth, and if your customers need heavy slicing and dicing.

SQL NoSQL
Relational model with data organized in a tabular structure. Differenent Model — document, graph, key value.
Pre-defined schema definition. Dynamic schema definition.
Typically vertically scalable — higher cost VMs. Horizontally scalable — lower cost VMs.
Powerful and standardized query interface. Query interface varies by provider.
Most implementations are ACID-compliant. Follows CAP (Consistency, Availability, Partitioning) .

You can use a SQL datastore for:

  • Manageable data sizes.
  • Low time period or size-based retention policies.
  • Low usage frequency.
  • Lightweight analytics.
  • Query interface needs to be standardized.

You can use a NoSQL for when:

  • Scale and volume are important.
  • Deep analytics are required.
  • Fast queries are paramount.
  • You can live with a non-standard query interface

Fuente: Relational vs. NoSQL Databases for API Traffic – DZone Database

MySQL does not need SQL | domas mituzas

MySQL does not need SQL Posted on 2016/08/03 by Domas Mituzas The “DBMS” part of MySQL is fine – storage engines (especially with new kids on the block), replication, etc, but it really sucks at executing SQL. I won’t even get into complex SQL that has complex data dependencies, will start with very basic tasks. SELECT * FROM table WHERE indexed = “A” LIMIT 1 If multiple indexes can satisfy the query, MySQL will hit each of them at least twice – looking up first “A” and last “A” records. It will do that w

Fuente: MySQL does not need SQL | domas mituzas