36,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Build effective RESTful APIs for enterprise with design patterns and REST framework's out-of-the-box capabilities
Key Features
- Understand advanced topics such as API gateways, API securities, and cloud
- Implement patterns programmatically with easy-to-follow examples
- Modernize legacy codebase using API connectors, layers, and microservices
Book Description
This book deals with the Representational State Transfer (REST) paradigm, which is an architectural style that allows networked devices to communicate with each other over the internet. With the help of this book, you'll explore the concepts of service-oriented architecture (SOA), event-driven architecture (EDA), and resource-oriented architecture (ROA). This book covers why there is an insistence for high-quality APIs toward enterprise integration.
It also covers how to optimize and explore endpoints for microservices with API gateways and touches upon integrated platforms and Hubs for RESTful APIs. You'll also understand how application delivery and deployments can be simplified and streamlined in the REST world. The book will help you dig deeper into the distinct contributions of RESTful services for IoT analytics and applications.
Besides detailing the API design and development aspects, this book will assist you in designing and developing production-ready, testable, sustainable, and enterprise-grade APIs. By the end of the book, you'll be empowered with all that you need to create highly flexible APIs for next-generation RESTful services and applications.
What you will learn
- Explore RESTful concepts, including URI, HATEOAS, and Code on Demand
- Study core patterns like Statelessness, Pagination, and Discoverability
- Optimize endpoints for linked microservices with API gateways
- Delve into API authentication, authorization, and API security implementations
- Work with Service Orchestration to craft composite and process-aware services
- Expose RESTful protocol-based APIs for cloud computing
Who this book is for
This book is primarily for web, mobile, and cloud services developers, architects, and consultants who want to build well-designed APIs for creating and sustaining enterprise-class applications. You'll also benefit from this book if you want to understand the finer details of RESTful APIs and their design techniques along with some tricks and tips.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 438
Veröffentlichungsjahr: 2019
Ähnliche
Hands-On RESTful API Design Patterns and Best Practices
Copyright © 2019 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Richa TripathiAcquisition Editor: Chaitanya NairContent Development Editor: Tiksha SarangTechnical Editor: Riddesh DawneCopy Editor:Safis EditingProject Coordinator: Prajakta NaikProofreader: Safis EditingIndexer: Pratik ShirodkarGraphics: Jisha ChirayilProduction Coordinator: Jyoti Chauhan
First published: January 2019
Production reference: 1310119
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78899-266-4
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the authors
Harihara Subramanianworks for the SABRE Corporation as a senior principal software architect. Hari has been working with software development and various software architecture concepts since 1999. He is an energetic and highly focused technology leader with a proven track record in software development, software architecture principles, and implementations. He has been an active contributor to various online and offline forums in different technologies, and focuses his time on technology consulting, software development, microservices architecture (MSA), Service-oriented architecture (SOA), and more.
Pethuru Raj(PhD) works as the chief architect at the Site Reliability Engineering Center of Excellence, Reliance Jio Infocomm Ltd. (RJIL), Bengaluru. Previously, he worked as a cloud infrastructure architect at the IBM Global Cloud Center of Excellence, IBM India, Bengaluru. He also had an extended stint as a TOGAF-certified enterprise architecture consultant in Wipro Consulting's services division and as a lead architect in the corporate research division of Robert Bosch, Bengaluru. He has more than 17 years of IT industry experience and 8 years' research experience.
About the reviewers
Kenneth Geisshirt is a software developer based in Copenhagen, Denmark. He is a chemist by education, and a geek by nature. Working for a small database vendor, he implements SDKs for various programming languages (including Java, JavaScript, and so on) for a variety of platforms (including Linux, Android, and macOS). He is a strong believer in open source software, and endeavors to contribute where and when he can. He has authored books on PAM, Git, Linux, and JavaScript, and he writes technical feature articles for computer magazines.
Harshad Kavathiya is a backend software developer with extensive industrial experience. He has worked for companies including Altair Engineering, Honeywell, CoWrks, and many more reputed multinational corporations. He is currently working for Accion Labs as a senior software engineer. Harshad holds an M.Tech in computer science from Manipal Institute of Technology, Manipal. His expertise lies in Python, data structures and algorithms, and MSA. He is passionate about real-time, scalable application development.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Hands-On RESTful API Design Patterns and Best Practices
About Packt
Why subscribe?
PacktPub.com
Contributors
About the authors
About the reviewers
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Conventions used
Get in touch
Reviews
Introduction to the Basics of RESTful Architecture
Technical requirements
Evolution of web technologies
Learning about Web 3.0
Learning about web service architecture
Discussing the web API
Learning about service-oriented architecture
Learning about resource-oriented architecture
Resource-oriented design
The benefits of ROA
Beginning with REST
REST architecture style constraints
Beginning with client-server
The client in client-server architecture
The service in client-server architecture
Understanding statelessness
Advantages and disadvantages of statelessness
Caching constraint in REST
Benefits of caching
Understanding the uniform interface
Identification of resources
Manipulation of resources
Self-descriptive messages
Hypermedia as the Engine of Application State
Layered systems
Code on demand
RESTful service mandates
Architectural goals of REST
Summary
Design Strategy, Guidelines, and Best Practices
Technical requirements
Learning about REST API and its importance
Goals of RESTful API design
Affordance
Loosely coupled
Leverage web architecture
API designer roles and responsibilities 
API design best practices
API design principles
Ubiquitous web standards
Flexibility
Granularity
Optimized APIs
Functionality
Learning about unusual circumstances
Community standardization
API playgrounds
RESTful API design rules
Learning about Uniform Resource Identifiers
URI formats
REST API URI authority
Resource modelling
Resource archetypes
URI path
URI query
HTTP interactions
Request methods
Response status codes
Metadata design
HTTP headers
Media types and media type design rules
Representations
Message body format
Hypermedia representation
Media type representation
Errors representation
Client concerns
Versioning
Security
Response representation composition
Processing hypermedia
JavaScript clients
Summary
Further reading
Essential RESTful API Patterns
Technical requirements
Beginning with the installations
Beginning with RESTful API patterns – part I
Statelessness
Content negotiation
Content negotiation with HTTP headers
URI templates
Design for intent
Pagination
Discoverability
Error and exception logging
Unicode
Summary
Advanced RESTful API Patterns
Technical requirements
RESTful API advanced patterns
Versioning
Versioning through the URI path
Versioning through query parameters
Versioning through custom headers
Versioning through content-negotiation
Authorization
Authorization with the default key
Authorization with credentials
Uniform contract
Entity endpoints
Endpoint redirection
Idempotent
Bulk operation
Circuit breaker
Combining the circuit pattern and the retry pattern
API facade
Backend for frontend
Summary
Further reading
Microservice API Gateways
Technical requirements
About microservice architecture
The prominent infrastructure modules in microservice-centric applications
Service registry 
Service discovery
Composition/orchestration 
Transformation 
Monitoring 
Load balancing and scaling 
High availability and failover 
HA and failover guidelines
Governance 
About API gateway solutions
API gateways for microservice-centric applications
The issues with microservice API gateways
Security features of API gateways
Prominent API gateway solutions
Service mesh versus API gateway
Summary
RESTful Services API Testing and Security
An overview of software testing 
RESTful APIs and testing
Basics of API testing
Understanding API testing approaches
API testing types
Unit tests
API validation tests
Functional tests
UI or end-to-end tests
Load testing
Runtime error detection tests
Monitoring APIs
Execution errors
Resource leaks
Error detection
REST API security vulnerabilities
Exposing sensitive data
Understanding authentication and authentication attacks
Understanding authorization and OAuth2 schemes
Cross-site scripting
Reflected XSS
Stored XSS
DOM XSS
Cross-site request forgery
Denial-of-service attack
Distributed denial of service
Injection attacks
Insecure direct object references
Missing function-level access control
Man-in-the-middle attacks
Common types of MITM attacks and protection measures
Replay attacks and spoofing
Causes of vulnerabilities
API design and development flaws
Poor system configuration
Human error
Internal and external connectivity
Security tests
Penetration tests or pen tests
Importance of penetration tests
Pen testing lifecycle
Preparation, planning, and reconnaissance
Scanning
Gaining access
Maintaining access
Analysis
Pen testing types for API testing
White-box penetration testing
Fuzz tests
The life cycle of fuzz tests
Fuzz testing strategy
Mutation-based fuzz tests
Generation-based fuzz tests
Advantages and disadvantages of fuzz tests
Back to API testing
API test cases
Essential aspects of API test cases and test case preparation
API testing challenges
Initial setup
API schema updates for testing
Testing parameter combinations
API call sequence
Validating parameters
Tracking system integration
API testing best practices
API testing tools
CQRS
Summary
Further reading
RESTful Service Composition for Smart Applications
Technical requirements
Briefing RESTful microservices
Demystifying the MSA style
The advantages of microservices
The emergence of cloud-native applications
The growing ecosystem of IoT device services
The changing application ecosystem
Tending toward the API-driven world
The Representational State Transfer service paradigm
API design best practices
Learning about service-composition methods
Service orchestration and choreography
Beginning with service orchestration
The shortcomings of service orchestration
Applying orchestration-based composition
Beginning with service choreography
The shortcomings of service choreography
Applying choreography-based composition
The hybridization of orchestration and choreography
Another example of the hybridization of orchestration and choreography
Choreography
Service choreography using the message broker
Service orchestration
Service orchestration using BPMN and REST
The hybridization – event-driven service orchestration
Data management 
Thinking in REST
Discarding SQL join
Eventual consistency
Polyglot persistence
Summary
RESTful API Design Tips
Technical requirements
Beginning with APIs
Learning about application programming interfaces
APIs have become indispensable
Learning about the major types of APIs
Describing API platforms
Creating API development platforms
API-integration platforms
Legacy integration
API management platforms
Demystifying the RESTful services paradigm
Characterizing the REST architecture style
REST Resource Representation Compression
Idempotent REST APIs
REST API design considerations
Enumerating RESTful API design patterns
Media types
API security design patterns
Whitelist allowable methods
Summary
Further reading
A More In-depth View of the RESTful Services Paradigm
Technical requirements
Tending toward the software-defined and software-driven world
Software-enabled clouds for the digital intelligence era
The IoT applications and services
Cloud-enabled applications
Cloud-native applications
Mobile, handheld, and wearable applications
Transactional, operational, and analytical applications
Knowledge visualization applications
Social applications 
Scientific and technical applications 
Centralized and distributed applications
Decentralized and intelligent applications with blockchain technology 
Composite and multi-container applications 
Event-driven applications 
High-quality applications
Resilient applications 
The REST paradigm for application modernization and integration
Application programming interfaces
Public APIs for external integration and innovation
Private APIs for internal purposes 
APIs for IoT devices
APIs for application integration
Describing the RESTful services paradigm
REST architectural constraints
The advantages of REST
Self-descriptive messages
SOAP versus REST
When to use REST versus SOAP
Best practices for REST-based microservices
The API-first approach
Developing API-first
Building services API-first
Summary
Further reading
Frameworks, Standard Languages, and Toolkits
Technical requirements
Core features of a framework
Spring Boot
Core features of Spring
Database integration with Spring data
Messaging integration
Extending Spring with auto-configuration
Writing unit tests and integration test cases
Benefits of Spring Boot
Drawbacks of Spring Boot
Beginning about Light 4j
Core features of Light 4j
Learning about Light Rest 4j
Light-code-gen
Choosing Light 4j over the rest
Spark Framework
Core features of Spark Framework
Creating an API with fewer lines
Benefits of Spark
Drawbacks of Spark
Dropwizard
Overview
Core features of Dropwizard
Jetty for HTTP
Jersey for REST
Jackson
Metrics
Liquibase
Other noteworthy features
Benefits of Dropwizard
Drawbacks of Dropwizard
Understanding Go framework for the RESTful API
An overview
Gin-gonic
Core features
HttpRouter
Http2 server push
Multi-template
Upload files
Other noteworthy features
Benefits of Gin-Gonic
Drawbacks of Gin-Gonic
Revel
Core features
Router
Server engine
Controllers
Handlers
Interceptors
Filters
Cache
Other noteworthy features
Benefits of Revel
Drawbacks of Revel
Python RESTful API frameworks
Overview of Python
Django
Django Rest Framework
Core features
Web-browsable API
Authentication
Serialization and deserialization
Other noteworthy features
Benefits of the DRF
Drawbacks of the DRF
Flask
Flask-RESTful
Core features of Flask-RESTful
Resourceful routing
Restful request parsing
Output fields
Other noteworthy features
Benefits of the Flask framework
Drawbacks of Flask
Frameworks – a table of reference 
Summary
Further reading
Legacy Modernization to Microservices-Centric Apps
Technical requirements
A preview of containers and microservices
Introducing the microservices architecture
Why legacy modernization?
Legacy-to-digital application modernization
Accomplishing modernization
Approaching legacy application modernization
Microservices-centric legacy application modernization
Service extraction 
Service composition 
Service migration
Container-centric legacy application modernization
Refactoring and rewriting
Modernization technique terms
Legacy modernization through microservices
The distinctions of microservices
The code samples
The major hurdles to overcome
Modernizing and migrating legacy applications – the role of cloud environments
The need for cloud environments
A case study for legacy modernization and migration
The combination of microservices and serverless computing speeds up legacy modernization
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
This book is intended to empower you with knowledge of API design principles and best practices, such that you will be ready to design highly scalable, reusable, adaptable, and secured RESTful APIs. This book also introduces some common and some emerging patterns in the most indispensable domain of RESTful APIs.
RESTful patterns impact various layers of web services that span across multiple functions, such as CRUD operations, databases, presentation layers, applications, and infrastructure layers. Other prominent and dominant patterns in the RESTful domain include communication, integration, orchestration, security, management, software deployment, and delivery. This book will help you become familiar with the most significant patterns, such as client/server discovery, API gateways, API compositions, circuit breakers, enterprise security, content negotiation, endpoint redirection, idempotent capability, API façades, and many more essential patterns.
While this book predominantly covers medium-level to advanced-level topics about RESTful APIs, it covers a few basics of service-oriented architectures and resource-oriented web service architectures as well, to help you gain a better understanding of what's being covered more quickly.
Who this book is for
This book is for anyone who needs a comprehensive yet simple-to-understand resource to help them with their RESTful API design and development skills and expose them highly adoptable RESTful APIs that give insights into best practices and key principles, along with proven RESTful API design patterns.
What this book covers
Chapter 1, Introduction to the Basics of RESTful Architecture, intends to refresh your understanding of a few fundamental concepts of the web, its architecture, and the way it is evolving, hoping to lay a firm foundation for RESTful service designs and applications. We will discuss World Wide Web layers and architecture, web API development models, and REST-based service communications. You will also be introduced to service-oriented and resource-oriented architecture principles and characteristics, then move on to the foundations of REST's principles, constraints, qualifiers, and goals.
Chapter 2, Design Strategy, Guidelines, and Best Practices, discusses a few essential API design guidelines, such as consistency, standardization, reusability, and accessibility through REST interfaces, aiming to equip API designers with better thought processes for their API modelling. Also, this chapter intends to introduce a few practices for better REST API implementations, along with a few common, but avoidable, mistakes of API strategies.
Chapter 3, Essential RESTful API Patterns, provides both information about the concepts and also practical code examples to do with common and fundamental design patterns of RESTful APIs, so that you can better understand and power your RESTful API services. As part of this chapter, you will learn a few common and essential API design patterns, such as content negotiation, URI templates, pagination, Unicode, and more, along with the code implementation of those patterns. Each pattern addresses the RESTful constraints, and helps you to ensure that these essential patterns are accounted for in your API designs and implementations.
Chapter 4, Advanced RESTful API Patterns, is the second part of our look at API design patterns, and intends to discuss a few advanced design patterns, versioning, backend for frontend, authorization, idempotence and its importance, and how to power APIs and delight customers with bulk operations APIs.
Chapter 5, Microservice API Gateways, mainly talks about the crucial contributions of API gateway solutions to making microservices vital to producing enterprise-scale, mission-critical, cloud-hosted, event-driven, production-grade, and business-centric applications. We discuss popular API gateway solutions in this chapter and also look at the implementation of an aggregation service through the API gateway.
Chapter 6, RESTful Services API Testing and Security, intends to take you on an API testing journey, looking at types of API tests, challenges in API testing, and security in API testing. You will get a glimpse of various API testing tools, API security tools, and frameworks, and also learn how you can expose any security issues and API vulnerabilities as part of API testing, quality, and security measures.
Chapter 7, RESTful Service Composition for Smart Applications, is specially crafted to tell you all about the contributions of the RESTful services paradigm toward designing, developing, and deploying next-generation microservices-centric and enterprise-scale applications. It looks at how RESTful services that are capable of finding and binding with one another results in process-aware, business-critical, and people-centric composite services. You will understand the need for service composition, various compositions methods such as orchestration and choreography, and also the use of hybrid versions of orchestration and choreography for smarter applications.
Chapter 8, RESTful API Design Tips, discusses the design patterns and best practices needed for building competent and compatible REST APIs that can easily keep up with technological and business changes. This chapter deals with the importance of APIs; API design patterns and best practices; API security guidelines; the various tools and associated platforms of API design, development, integration, security, and management; and trends in the API-driven digital world.
Chapter 9, A More In-depth View of the RESTful Services Paradigm, focuses on conveying the emerging techniques and tips for producing RESTful services and their corresponding APIs. We discuss methodologies such as software-defined and driven world, and emerging application types that help in quick and easy deployments of APIs. Also, this chapter discusses topics such as the REST paradigm for application modernization and integration, RESTful services for digital transformation and intelligence, and the best practices for REST-based microservices.
Chapter 10, Frameworks, Standard Languages, and Toolkits, introduces you to a few prominent frameworks that can come in handy when deciding on the right framework for your API development needs. It discusses a few prominent frameworks for app developers who want to kick-start their RESTful APIs and microservices with their acquainted programming languages. This chapter is an attempt to provide you with information on a few programming language-friendly frameworks so that you can pick the most suitable framework for your RESTful API development needs. Also, this chapter has a reference table for various frameworks and their supported languages, along with their prominent features.
Chapter 11, Legacy Modernization to Microservices-Centric Apps, discusses how microservices architectures (MSAs) are the way forward for modern applications that are highly nimble, versatile, and resilient. This chapter provides the reasons for legacy application modernization, delineating why applications have to be modernized to be migrated and run in cloud environments, discussing how the combination of microservices and containers is the best way to achieve legacy modernization, and detailing legacy modernization methodologies.
To get the most out of this book
As this book presents many web services and RESTful services concepts, there are no specific requirements for you to follow; however, if you want to run and execute the code samples provided in the book (which you should), then you need a basic understanding of Java programming languages, Maven, or knowledge of any build tools.
The chapters with sample code have clear explanations of how to run and test the samples, and come with the build and run scripts as well.
Download the example code files
You can download the example code files for this book from your account at www.packtpub.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packtpub.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of the following software:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Hands-On-RESTful-API-Design-Patterns-and-Best-Practices. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "The four basic HTTP operations: GET, POST, PUT, and DELETE."
A block of code is set as follows:
@GetMapping({"/v1/investors","/v1.1/investors","/v2/investors"}) public List<Investor> fetchAllInvestors() { return investorService.fetchAllInvestors(); }
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
public
interface
DeleteServiceFacade {
boolean
deleteAStock(String investorId, String stockTobeDeletedSymbol);
boolean
deleteStocksInBulk(String investorId, List<String> stocksSymbolsList);}
Any command-line input or output is written as follows:
$ mkdir css
$ cd css
Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "The Pipeline entity is entirely responsible for orchestrating control and data flows"
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
Introduction to the Basics of RESTful Architecture
A web service is a software service or a software functionality provided by one set of computing devices to another set of computing devices. These devices communicate using established or standardized communication protocols through the World Wide Web (WWW).
This chapter intends to refresh your understanding of a few fundamental concepts of the web and its architecture, and the way it is evolving, hoping to lay a firm foundation for RESTful service designs and applications. The following topics are covered in this chapter:
A brief history of the WWW and its evolution
WWW layers and architecture
Web API development models and REST-based service communication
A brief introduction to service-oriented architecture
Resource-oriented architecture principles and characteristics
Introduction to REST
REST constraints
RESTful qualifiers
REST architecture goals
Technical requirements
As this book deals with intermediate to advanced topics of RESTful design patterns, we expect you to have a good understanding of web service concepts and their unique functions. As mentioned earlier, this chapter is an attempt to refresh your understanding of various fundamental concepts of the WWW, its evolution, and the types of web services it offers, so there are no formal technical requirements for this chapter.
Evolution of web technologies
Generally, the aim of this book is to provide more elaborate RESTful patterns; however, this section intends to give you a quick introduction to web services and their evolution since the early 1990s, giving you exciting facts about Web 1.0 through to Web 3.0, and then moving on to details about service-oriented architecture (SOA) and resource-oriented architecture (ROA).
As you are aware, today's web is a universe in itself, with a massive amount of interlinked web-based apps, images, videos, photos, and various interactive content. Which web technologies have made this possible, where did it start, how has it evolved over time, and how does it enable web app developers to develop amazing and interactive web experiences?
The following diagram provides a brief overview of the WWW and its evolution over time. Please note that each web version has its enabling technologies mentioned in the corresponding box:
Let's discuss Web 3.0 more and focus on web services and their evolution as part of the third generation.
Learning about Web 3.0
The following sections focus on Web 3.0 and the evolution and history of web services.
Web 3.0 is generally referred to as executing semantic web, or read-write-execute web. Web 3.0 decentralizes services such as search, social media, and chat applications that are dependent on a single organization to function. Semantic and web services are the primary constituents of Web 3.0.
The following diagram depicts layers of typical Web 3.0 constructs. The semantic web layers are Static Web, Translations, and Rich Internet Applications (RIA) or Rich Web built on top of the internet:
This data-driven web adjusts according to the user's searches, for instance, if a usersearches for architecture patterns, the advertisements shown are more relevant to architecture and patterns; it even remembers your last search and combines the last searched queries as well. Interesting isn't it?
What you see in the following diagram is a Web 3.0 stack, with various building blocks as URI, Unicode representations, syntax (XML/JSON), RDFS taxonomies, and so on; they constitute a Web 3.0 stack:
Let's move on to the web service architecture, the specifications, and the communication protocols, as they are the fundamentals before we move to ROA, SOA, and Representational State Transfer(REST) or RESTful services.
Learning about web service architecture
Web services are a method of communication between two computing devices over a network, and the communication happens in standardized ways (and specifications) for the integration of heterogeneous web applications using XML/JSON, SOAP, WSDL, and UDDI. XML/JSON is the data format that provides metadata for the data that it contains; SOAP is used to transfer data; WSDL is used for defining available services to be consumed, and UDDI will have the list of services available.
Web services architecture (WSA) mandates the presence of certain characteristics, and suggests a few optional ones, when developing any web service.
WSA consists of three significant roles, as you can see in the following diagram, and they are as follow:
Service Provider
Service Consumer
Service Broker
This is shown in the following diagram:
The Service Requestor finds the Service Provider through UDDI, and contacts the provider using the Simple Object Access Protocol (SOAP). The Service Provider then validates the service request and responds to the requestor with XML/JSON as a service response.
Discussing the web API
So far, we have discussed the fundamentals of the client-server/web services paradigm, and the way they communicate with standard protocols; however, we are yet to touch upon REST-based communication and after all, that's what this book is about. This section will cover the introduction of web APIs, and how a web API is a development model for web services. The communication between the devices is REST-based. RESTful APIs do not use/require XML- based web service protocols, such as SOAP or WSDL, to support their interfaces, but they use simplified representations instead.
The following diagram depicts the web API and their simplified representations as the client side and the server side are exposed to each other through high-level interfaces:
So the web API, as shown in the preceding diagram, is available on both the client side and the server side. The client-side interfaces are generally exposed as JavaScript or browser plugins, and the server-side interfaces are generally exposed through the web as JSON/XML. Some of the key terminologies that we will come across concerning web APIs are endpoint, uniform resource identifier (URI), and resources.
The web API is anapplication programming interface(API) for either a web server or for a web browser. So, Web API is a concept or methodology for accessing any API (available over the web) through the HTTP protocol. There are many categories of APIs, SOAP, XML-RPC, JSON-RPC, REST, and so on. APIs can be developed with any programming language such as Java, .NET, and many more.
So now you have got an idea of what is a Web API is and where REST API development fits into the Web API landscape, let's move on and see more details of SOA, ROA, REST, RESTful APIs, and their key constituents in the following sections.
Learning about service-oriented architecture
Service-oriented architecture is an architectural style of web services. It defines some standards and lays down best approaches to design and develop a web service. Any web service is the logical representation of repeatable business activities that have a specified outcome, such as retrieving a weather report for a particular city, accessing stock prices for a given stock, updating a record to an inventory service, and so on. SOA is self-contained, and also provides guidelines to combine a service with other services as well. Another fact about SOA is that it is a black box (or abstract) to the service consumer who consumes it.
In short, SOA is essentially a collection of services, those services communicate with each other, and a service is an operation or a function that is well defined, self-contained, and independent of other service contexts and states. Services are applications hosted on application servers and interact with other applications through interfaces.
Learning about resource-oriented architecture
Resource-oriented architecture is a foundation of the semantic web (please refer to the Web 3.0 section of this chapter). The idea of ROA is to use basic, well-understood, and well-known web technologies (HTTP, URI, and XML) along with the core design principles.
As we all know, the primary focus of web services is to connect information systems, and ROA defines a structural design or set of guidelines to support and implement interactions within any connected resources. Any business entity can be represented as a resource, and it can be made accessible through a URI.
For example, in an organization's human resource system, each employee is an entity, and salary, employee details, and profiles are associations (descriptors) of that entity.
The following is a quick comparison table for object-oriented and resource-oriented concepts, and it gives a quick insight as to what ROA is:
Objects in object-oriented architecture
Resources in ROA
Every entity is defined as an object
Entities are services
An object has attributes and actions
A service has descriptions and contracts
Objects need to maintain state to interact
Interacts over the network with a defined location or address
Resource-oriented design
The resource-oriented design section intends to walk you through the ROA design guidelines, design principles, and characteristics, along with its properties as well. Having introduced ROA properties, we will look at REST architecture in subsequent sections.
ROA-based web services describe a self-discoverable entity, and modeling is based on its logical form (unlike services, as they are based on the technical form).
Let's look at the basic blocks of ROA such as resources, representations, and so on in the following diagram:
The blocks in the preceding diagram represent the typical structure of ROA and give an idea of how resources are consumed by the service consumers.
Let's briefly consider the concepts and properties of ROA, as follows:
Resource providers
: Resource providers expose the resources for the service consumers to invoke the services with HTTP methods. Microsoft Azure and Amazon AWS are simple examples of resource providers.
Resource
: A resource is an explicit reference to an entity that can be identified and assigned and, most importantly, referenced as a resource. Some examples of resources could be servers, devices, web pages, JavaScript, or the latest version of software, the latest defect in software, a directory or list of information about an organization, and so on.
Resource name
: The resource name is the unique name or identification for the resource. So, no two resources can point to the same data. For instance, the latest version of software is 2.0.9.
Resource representation
: Resource representation is the useful information about the current state of a resource, specified with a specific format, in a specific language.
Resource link and connectedness
: Represents (linkage) another resource or the resource itself. Connectedness is all about how reliable and relevant the resource's links are.
Resource interface
: The resource interface is an interface for accessing the resource and handling its state.
Addressability
: Addressability is exposing datasets or functionalities as a resource, and the addressability of a resource happens through URIs.
Statelessness
: Statelessness is maintaining the isolation and independence of client and server states. Every request from the client should be self-contained.
The uniform interface
: Every service needs to use the HTTP interface the same way, such as
GET
,
POST
,
PUT
,
DELETE
, and so on. The uniform interface simply means using some common nomenclature that is interpreted the same way across the web. For example,
GET
does mean get (read) something.
The following table summarizes the HTTP operations that can be used to implement an ROA-based web service:
HTTP operation
Description
GET
Read the resource representations
PUT
Create a new resource
DELETE
Delete the resource (optionally linked resource as well)
POST
Modify the resource
HEAD
Meta information of the resource
The preceding table shows the HTTP methods to implement ROA.
The benefits of ROA
The following are the benefits of ROA:
Independent of client contracts
: Free from interface agreements/contract formulations, that is, no need to formulate the contact as the entire web is based on HTTP operations.
Explicit state
: As the resource itself represents states, servers won't receive unknown application specific payloads; the server does not have to keep track of the client who called the server, and also the client doesn't need to know which server it has talked to.
Scalability and performance
: Scalability with ROA is shown by characteristics such as no contract boundaries, explicit states, and freeing up the clients from the server's stickiness(session). The performance improvement regarding response time for the ROA caching, load-balancing, indexing, and searching play a significant role in improving performance.
Beginning with REST
So far, we have looked at ROA and a set of guidelines, such as statelessness, resources, addressability, uniform resources, and so on. Those guidelines are the fundamental implementation of REST architecture. As this book is all about RESTful patterns, we are going to explore more about the REST architectural style in this section.
The REST concepts were submitted as a PhD dissertation by Roy Fielding. The fundamental principle of REST is to use the HTTP protocol for data communication (between distributed hypermedia systems), and it revolves around the concept of resources where each and every component considered as a resource, and those resources are accessed by the common interfaces using HTTP methods:
The preceding diagram shows you where REST stands in the ROA architecture and how it can be accessed by different consumers.
REST is an architectural style and not a programming language or technology. It provides guidelines for distributed systems to communicate directly using the existing principles and protocols of the web to create web services and APIs, without the need for SOAP or any other sophisticated protocols.
The REST architecture is simple and provides access to resources so that the REST client accesses and renders the resources on the client side. In REST style,URI or Global IDs helps to identify each resource. As you know REST uses several resources representations to represent its type such as XML, JSON, Text, images and so on.
REST architecture style constraints
There are design rules that are applied to establish the different characteristics of the REST architectural style, which are referred to as REST constraints:
The preceding diagram depicts REST constraints in a typical web/internet-based application. The following are the REST constraints:
Client-server
Statelessness
Cacheable
Uniform interface
Layered systems
Code on demand
Beginning with client-server
The client-server architecture or model helps in the separation of concerns between the user interface and data storage:
Let's discuss the client and server in the context of ROA as follows:
Client
: It is the component that is the requestor of a service and sends requests for various types of services to the server
Server
: It is the component that is the service provider and continuously provides services to the client as per the requests
Clients and servers typically comprise distributed systems that communicate over a network.
The client in client-server architecture
There is no upper bound on the number of clients that can be serviced by a single server. It is also not mandatory that the client and server should reside in separate systems. Both client and server can reside in the same system, based on the hardware configuration of the system and the type of functionality or service provided by the server. The communication between client and server happens through the exchange of messages using a request-response pattern. The client basically sends a request for a service, and the server returns a response. This request-response pattern of communication is an excellent example of inter-process communication. For this communication to happen efficiently, it is necessary to have a well-defined communication protocol that lays down the rules of communication, such as the format of request messages, response messages, error handling, and so on. All communication protocols that are used for client-server communication work in the application layer of the protocol stack. To further streamline the process of client-server communication, the server sometimes implements a specific API that can be used by the client for accessing any specific service from the server.
The service in client-server architecture
The term service used in the context of client-server architecture refers to the abstraction of a resource. The resource could be of any type and based on the one provided by the server (service); the server is named accordingly. For example, if the server provides web pages, it is called a web server, and if the server provides files, it is called a file server, and so on. A server can receive requests from any number of clients at a specific point in time. But any server will have its own limitations about its processing capabilities. Often, it becomes necessary for a server to prioritize the incoming requests and service them as per their priority. The scheduling system present in the server helps the server with the assignment of priorities.
Client-server benefits are in addition to separation of concerns and help with the following:
Improving the portability of the user interface
Improving scalability by simplifying server implementations
Developing with standalone, independent testable components
Understanding statelessness
The statelessness constraint helps services to be more scalable and reliable. Statelessness, in the REST context, means that all the client requests to the server carry all the information as explicit (stated), so that the server understands the requests, treats them as independent, and those client requests keep the server independent of any stored contexts. Keeping the session state within the client is important to manage this constraint in the services.
The following diagram shows the Service Consumer (client) and the Service States are independent and managed within the client and server respectively:
The statelessness constraint imposes significant restrictions on the kind of communications allowed between services and consumers, to achieves its design goals. The following are the restrictions to achieve statelessness:
It is the complete responsibility of the client to store and handle all the application states and the related information on the client side.
The client is responsible for sending any state information to the server whenever it's needed.
No session stickiness or session affinity on the server for the calling request (client).
The server also needs to include any necessary information that the client may need to create a state on its side.
HTTP interactions involve two kinds of states, application state and resource state, and statelessness applies to both. Let's see how the statelessness constraint is handled in each state:
Application state:
The data that is stored on the server side and helps to identify the incoming client request, using the previous interaction details with current context information
Resource state:
This is referred to as a resource representation, and it is independent of the client (the client doesn't need to know this state unless it is available as response is needed), and this is the current state of the server at any given point in time
Advantages and disadvantages of statelessness
The following are some advantages of statelessness:
As the server does not need to manage any session, deploying the services to any number of servers is possible, and so scalability will never be a problem
No states equals less complexity; no session (state) synchronize logic to handle at the server side
As the service calls (requests) can be cached by the underlying application, the statelessness constraint brings down the server's response time, that is, it improves performance with regard to response time
Seamless integration/implementation with HTTP protocols is possible as HTTP is itself a stateless protocol
Improves visibility as each request is its own resource and can be treated as an independent request
Improves reliability as it can recover from partial failures
The following are some disadvantages of statelessness:
Increase per-interaction overhead
Each request of webservices needs to get additional information so that it get parsed (interpreted) so that the server understands the client state from the incoming request and takes care of the client / server sessions if needed
Caching constraint in REST
Caching is the ability to store frequently accessed data (a response in this context) to serve the client requests, and never having to generate the same response more than once until it needs to be. Well-managed caching eliminates partial or complete client-server interactions and still serves the client with the expected response. Obviously, caching brings scalability and also performance benefits with faster response times and reduced server load.
As you can see in the next diagram, the service consumer (Client) receives the response from the cache and not from the server itself, and a few other responses are directly from the server as well. So, caching helps with the partial or complete elimination of some interactions between the service consumers and so helps to improve efficiency and performance (reduced latency time in response):
There are different caching strategies or mechanisms available, such as browser caches, proxy caches, and gateway caches (reverse-proxy), and there are several ways that we can control the cache behavior, such as through pragma, expiration tags, and so on. The following table gives a glimpse of the various cache control headers one use to can fine-tune cache behaviors:
Headers
Description
Samples
Expires
Header attribute to represent date/time after which the response is considered stale
Expires: Fri, 12 Jan 2018 18:00:09 GMT
Cache-control
A header that defines various directives (for both requests and responses) that are followed by caching mechanisms
Max age=4500, cache-extension
E-Tag
Unique identifier for server resource states
ETag:uqv2309u324klm
Last-modified
Response header helps to identify the time the response was generated
Last-modified: Fri, 12 Jan 2018 18:00:09 GMT
For more about cache-control directives. Please refer to https://tools.ietf.org/html/rfc2616#section-14.9.
Benefits of caching
Obviously, there are a lot of benefits to caching frequently accessed data, and the following are the significant ones:
Reduced bandwidth
Reduced latency (faster response time)
Reduced load on the server
Hide network failures and serve a client with the response
The cache constraint builds upon the client-server and stateless ones, with the requirement that responses are implicitly or explicitly labeled as cacheable or non-cacheable.
Understanding the uniform interface
As we mentioned earlier in the uniform interface section as part of ROA, REST-based services can use the HTTP interface, such as GET, POST, PUT, DELETE, and so on, to maintain uniformity across the web. The intention of a uniform interface is to retain some common vocabulary across the internet. For example, GET does mean to get (read) something from the server. The services can independently evolve as their interfaces simplify and decouple the architecture, and the uniform interface brings a uniform vocabulary to those resources as well. The following diagram depicts the combination of HTTP Methods and the Resource Names for Uniform Interfaces:
There are four guiding principles suggested by Fielding that constitute the necessary constraints to satisfy the uniform interface, and they are as follows:
Identification of resources
Manipulation of resources
Self-descriptive messages
Hypermedia as the engine of application state
We will see each constraint in detail in the following sections.
Identification of resources
As we have seen in earlier sections, a resource represents a named entity in a web application, and it is usually a Uniform Resource Locator (URL). So, an entity can be identified and assigned as a resource by an explicit reference to it.
A URL in a web application is usually a link, and it is in fact a URI. For example, a home page URI, https://developer.twitter.com, uniquely identifies the concept of a specific website's root resource. In REST constraints, the URIs we use are described as follows:
The semantics of the mapping of the URI to a resource must not change. For instance, Twitter's
https://api.twitter.com/1.1/statuses/retweets/:id.json
as a URI may never change, and of course the contents or values will keep improving, according to the latest updates.
Resource identification is independent of its values so two resources could point to the same data at some point, but they are not the same resource.
For example, URI 1,
https://api.twitter.com/1.1/statuses/retweets/:id.j
so
n
, returns a collection up to 100 of the most recent retweets of a tweet (specified by the ID).
The other URI 2,
https://api.twitter.com/1.1/statuses/retweeters/ids.json
,
responds with a collection of 100 user IDs (maximum) belonging to users who have retweeted the tweet (specified by the ID parameter)
.
URIs bring benefits such as only one way to access a resource, dynamic media types for resource responses (serve the media type at the time it is requested) with the help of the
Accept
headers,
and clients accessing those dynamic resources do not need to change any identifiers if any change is made in the response content type.
