The History of Web Services and Machine Communication

There is a long and rich history of using web services to communicate between applications and systems throughout the Internet. Even before there was an Internet or World Wide Web there was machine communication. For almost 40 years, companies have had a standard for communicating between computers. The Electronic data interchange (EDI) method has had many standards through the years (including X12, EDIFACT, ODETTE). The EDI methods were created to save money for companies that built networked systems which could communicate in this manner. They saved a great deal of human interaction, as well as minimized the need for paper documents to be transported and stored. The downside of using EDI was the high cost of time and money required to implement a solution. What’s more, adopting EDI required a change in business process which was limiting for many companies. For very large corporations EDI was successful, but for reasons stated above, out of reach for many smaller organizations.

With the creation of the World Wide Web (WWW) by English scientist Tim Berners-Lee in the early 1990’s, some of the barriers with machine communication were reduced. By leveraging the TCP/IP protocol standard of the Internet, Berners-Lee and his team created the Hypertext Transfer Protocol (HTTP) for allowing applications on the WWW to exchange or transfer hypertext (or as we call it now HTML) effectively and cheaply. The proliferation of the Internet by both consumers and business organizations allowed the rise of the early Web Service methods to make the Internet a more valuable resource for companies looking for business optimization and better workflows.

There have been a number of technologies used for creating and implementing web services since the creation of the WWW. Many of the early web service technologies relied on heavy definitions to handle everything that was needed for machine communications: security, encryption, error handling, etc. This made web service technologies like CORBA, RPC or SOAP difficult to design, implement and finally test. They all shared the challenges: keeping track of state on the server during the lifetime of the communication with each client and the performance needed for today’s Enterprise systems and mobile applications. Because of these deficiencies in earlier Web Service technologies and implementations, new visions were needed in the Web 2.0 period of the Internet.

What is REST?

REST stands for Representational State Transfer. It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

IN MANY WAYS, THE WORLD WIDE WEB ITSELF, BASED ON HTTP, CAN BE VIEWED AS A REST-BASED ARCHITECTURE.

REST applications use HTTP requests to post data (POST and PUT), read data (GET), and delete (DELETE) data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations. In addition, REST uses HTTP status codes to give clients the information for the actions they took. The HTTP status codes (200, 201, 404, etc.) are all very common to developers.

REST is not a “standard”. There will never be a standards recommendation for REST, for example. And while there are REST programming frameworks and 3rd party systems, working with REST is so simple that your organization can often create a custom solution with standard library features in languages like Node.js, Java, or C#/ASP.NET Web API.

The REST architectural style describes five constraints. These constraints, applied to the architecture, were originally documented by Roy Fielding in his doctoral dissertation (see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm ) and defines the basis of the REST style.

The six constraints are: (click the constraint to read more)

  • Uniform Interface
    • Despite being simple, REST is fully-featured; there’s basically nothing your organization can do in other Web Services that can’t be done with a REST architecture.
  • Stateless
    • The necessary state to handle a request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Then after the server does it’s processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.
  • Cacheable
    • As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
  • Client-Server
    • The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
  • Layered System
    • A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.

Why is REST and an API Management Platforms the Way to Create Your Enterprise APIs

There are many reasons why your organization should embrace and use REST APIs for their data and information needs.

DESPITE BEING SIMPLE, REST IS FULLY-FEATURED; THERE’S BASICALLY NOTHING YOUR ORGANIZATION CAN DO IN WEB SERVICES THAT CAN’T BE DONE WITH A REST ARCHITECTURE.

As your organization builds Enterprise and mobile apps for customers, partners, and employees, you need apps that perform well over different network types and speeds. And that means your organization need a great, REST APIs that provides design-time and runtime access to data services hosted by your infrastructure. Think of it as “cloud” technology that lets the data inside your datacenter get out and back (securely) to the mobile app that needs it. As mobile apps get more transactional, the need for API management platforms will become even more critical.

As these enterprise and mobile applications get complex, with transactions, integrated applications, and more and richer content and collaboration, they will need solutions that handle all those integration points. Think of it this way: REST interfaces give your organization the means, but now your organization needs a system to handle the sheer number of APIs your organization will be building.

You need to stay flexible with mobile platforms. Your organization might be able to get away with supporting only Android and iOS today, but before your organization knows it, you may need to support more form factors or additional platforms like Windows 10. And you may need to get data from sensors or Internet of Things (IoT) devices. REST APIs gives a consistent, accessible interface with a low bar to entry. As long as a device connects to the web your organization can send and consume data from the device. And if you make your APIs public, your organization might not even have to write that new mobile app because another developer could do it for you.

word-image

word-image1

 

 

 

The Benefits of an API Management Platform

The selection and use of an API Management System (AMS) ensures that your organization’s API program reaches its fullest potential. With API management, your organization can publish web services as APIs reliably, securely, and at scale.

Use an API Management System to drive API consumption among internal employees, external partners, and developers, while benefiting from the business and operational insights available in many of the API Management System. An API Management System gives you the tools your organization needs for end-to-end API management—provisioning user roles; creating usage plans and quotas; applying policies for transforming payloads; and setting up throttling, analytics, monitoring, and alerts.

Accelerate API Adoption

A first-class developer experience is key to attracting developers to your organization’s API platform and retaining them. Easily expose a developer portal for your organization’s APIs that provides documentation and test experiences and minimizes the time to the first successful API call.

Secure and Protect Your APIs

Protect your organization’s mission-critical systems with authentication, rate limiting, and quotas. Connect to back ends using their native authentication protocol, and unify them at the front end. Use caching to ease loads under pressure.

Use Analytics for Results

Understand how developers are using APIs, and act on those insights to deliver increased value. Identify the trends that are the most impactful to your organization: Visualize API performance, error rates, and adoption in near real time.

Increase API Discoverability and Usability

Most organizations now have thousands of APIs, and cross-team collaboration is hampered by fragmented experiences, poor documentation, and limited discoverability. Deploy API Management to create a unified façade and API catalog and increase business agility.

What Questions to ask when selecting an API Management Platform

So which API management platform should your organization use? It really depends on the situation. To pick the right platform, IT leaders will need to make sure their infrastructure, operations and application development teams have addressed the following:

What factors do we care most about? Security? Cost? The ability to scale out to consumer markets? All of the above? Remember that different factors may matter for different audiences or scenarios. Your priorities here will make the next question easier to answer.

What’s the best architecture — gateway, cloud-proxy, or “application-specific” — for our mobile and smart product applications? Note that your organization may need a different architecture or solution for customer applications than for internal employee applications.

How does the API management platform work with the other systems and tools we have in place? For example, if your organization is a Microsoft shop, then a Microsoft solution using Microsoft’s technologies along with specialized partner solutions is probably the best path with your organizations existing development approach and toolset. This combination of API management, app deployment and operations middleware is going to consolidate into an “engagement platform” that will be a big budget line item for your mobile and enterprise applications.

Leave a Reply

Your email address will not be published. Required fields are marked *