A Need for REST APIs and API Development Management
A Need for REST APIs and API Development Management
There's a rich history of using web services to communicate between apps and systems. Companies have always had a standard for communicating with computers.
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
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. These methods were created to save money for companies that built networked systems which could communicate in this manner. The downside of using EDI was the high cost of time and money required to implement a solution. This allowed adopting EDI for very large corporations but for reasons stated above, out of reach for many smaller companies and organizations.
With the creation of the World Wide Web by English scientist Tim Berners-Lee in the early 1990s, some of the barriers to 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 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 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 and defines the basis of the REST style.
In short, the constraints are:
1. Uniform Interface
Despite being simple, REST is fully-featured; there’s basically nothing your organization can do on other Web Services that can’t be done with a REST architecture.
The necessary state to handle a request is contained in 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 its processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.
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.
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.
5. 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.
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.
So, API Management?
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 needs a great REST API 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.
But even before you start to do API management, your organization needs to develop the REST API services.
Yes, But First - API Development
Now that most of the companies are starting to think why companies must have a REST API, many of them face the same challenges with one of the biggest challenges is figuring out a winning API strategy. When a company decides to start a new mobile project, they first develop the business requirements, and then start building the actual software. Usually there is a client-side team that designs the application, a server-side team that builds the back-end infrastructure and the testing team responsible to test both client-side and server-side outputs. These three or more teams must work together to develop a REST API for the project.
The REST API's are always changing, with each change the R&D teams are forced to refactor their work which extends development time and delivery dates (time-to-market), communication and collaboration about such changes are not sufficient, consuming valuable time.
In order to get you started with design, development, documentation and testing of your REST APIs, enhancing team collaboration and providing tools to rapidly build your API services you can look at RestCase - API Design, Documentation, and Testing for Teams.
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.
Many companies face the same challenges with one of the biggest challenges is figuring out a winning API strategy. When a company decides to start a new mobile project, they first develop the business requirements and then start building the actual software. Usually, there is a client-side team that designs the application, a server-side team that builds the back-end infrastructure and the testing team responsible to test both client-side and server-side outputs. These three or more teams must work together to develop a REST API for the project.
The modern enterprise may need hundreds or even thousands of mobile applications and so the API building process continues over a few years with different developers, consultants, and contractors. Many companies are already running with hundreds of internal APIs that lack management, are difficult to discover and document, and hard to use by internal developers, existing applications and partners.
Published at DZone with permission of Guy Levin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.