Building An Api Product Design Implement And Release Api Products That Meet User Needs Pedro

Building An Api Product Design Implement And
Release Api Products That Meet User Needs Pedro
download
https://ebookbell.com/product/building-an-api-product-design-
implement-and-release-api-products-that-meet-user-needs-
pedro-56049126
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Building An Api Product Bruno Pedro
https://ebookbell.com/product/building-an-api-product-bruno-
pedro-56267224
Building An Innovation Powerhouse Maximising People Potential To Grow
Your Business Andy Wynn
https://ebookbell.com/product/building-an-innovation-powerhouse-
maximising-people-potential-to-grow-your-business-andy-wynn-47277132
Building An Innovation Hotspot Approaches And Policies To Stimulating
New Industry Alicia Cameron
https://ebookbell.com/product/building-an-innovation-hotspot-
approaches-and-policies-to-stimulating-new-industry-alicia-
cameron-48776362
Building An Eventdriven Data Mesh Patterns For Designing Building
Eventdriven Architectures 1st Edition Adam Bellemare
https://ebookbell.com/product/building-an-eventdriven-data-mesh-
patterns-for-designing-building-eventdriven-architectures-1st-edition-
adam-bellemare-49473816

Building An Enterprise Chatbot Work With Protected Enterprise Data
Using Open Source Frameworks 1st Edition Abhishek Singh
https://ebookbell.com/product/building-an-enterprise-chatbot-work-
with-protected-enterprise-data-using-open-source-frameworks-1st-
edition-abhishek-singh-50195832
Building An Effective Security Program Chris K Williams Scott E
Donaldson Stanley G Siegel
https://ebookbell.com/product/building-an-effective-security-program-
chris-k-williams-scott-e-donaldson-stanley-g-siegel-51027388
Building An Emerald City A Guide To Creating Green Building Policies
And Programs 1st Edition Lucia Athens
https://ebookbell.com/product/building-an-emerald-city-a-guide-to-
creating-green-building-policies-and-programs-1st-edition-lucia-
athens-51389092
Building An Ark 101 Solutions To Animal Suffering Ethan Smith Guy
Dauncey Jane Dbe Phd Goodall
https://ebookbell.com/product/building-an-ark-101-solutions-to-animal-
suffering-ethan-smith-guy-dauncey-jane-dbe-phd-goodall-51602064
Building An American Empire The Era Of Territorial And Political
Expansion Paul Frymer
https://ebookbell.com/product/building-an-american-empire-the-era-of-
territorial-and-political-expansion-paul-frymer-51950650

Building an API Product
Copyright © 2024 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 author, 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.
Group Product Manager: Kunal Sawant
Senior Editor: Kinnari Chohan
Technical Editor: Vidhisha Patidar
Copy Editor: Safis Editing
Project Coordinator: Prajakta Naik
Indexer: Subalakshmi Govindhan
Production Designer: Prashant Ghare
Marketing DevRel Coordinator: Sonia Chauhan
First published: January 2024
Production reference: 1110124
Published by Packt Publishing Ltd.

Grosvenor House
11 St Paul’s Square
Birmingham
B3 1RB, UK
ISBN 978-1-83763-044-8
www.packtpub.com

To my wife, Vânia, and my two sons, Bernat and Enric. Without their ongoing love and support,
I wouldn’t have been able to write this book.
Contributors
About the author
Bruno Pedro is a computer science professional with over 25 years of experience in the industry.
Throughout his career, he has worked on a variety of projects, including internet traffic analysis, API
backends and integrations, and web applications. He has also managed teams of developers and
founded several companies, including Tarpipe, an iPaaS, in 2008, and the API Changelog in 2015. In
addition to his work experience, Bruno has also made contributions to the API industry through his
written work, including two published books on API-related topics and numerous technical magazine
and web articles. He has also been a speaker at numerous API industry conferences and events since
2013.
About the reviewers
David Roldán Martínez is currently the Head of APIs at Shaper by atmira. He also holds the
position of Associate Professor at the Universitat Politècnica de València (Spain) and is actively
involved as a researcher at VRAIN (Valencian Research of Artificial Intelligence Network).
Professionally, David is a Business and Solutions architect with over 25 years of experience in
software systems architecture. He holds a Ph.D. in Telecommunications Engineering and has a strong
educational background, including master’s degrees and extensive technological training.
Additionally, he is a scientific-technical evangelist, having authored more than thirty books.
David’s areas of expertise encompass APIs and their applications in various markets such as Banking,
Insurance, and Retail. He is well-versed in Artificial Intelligence, Digital Transformation, and the API
and Open Economy.
Christos Gkoros is a seasoned software engineer and architect with over 13 years of experience in
the industry. He has worked on a variety of projects in different technologies and industries, always
striving to find the best possible solution. With a focus on APIs, he is currently exploring ways to
help engineers in areas like API Design, API Management, and Strategy.
Christos has a proven track record of transforming complex challenges into streamlined, secure
systems, having spearheaded API design at Postman and microservice architecture at Vodafone. He is

passionate about mentorship and education and is committed to helping future talent grow and
succeed in the field.

Part 1: The API Product
1
What Are APIs?
The different types of APIs
Local APIs
Remote APIs
The history of APIs
Unix
Network APIs
The web
Available technologies and protocols
Communication protocols
Implementation technologies
Tools
Summary
2
API User Experience
Who uses APIs?
Industries
Personas
Developer experience
Second-degree user experience
API friction
Summary

3
API-as-a-Product
Business value
Monetization models
The freemium model
Tiered model
PAYG model
Support and documentation
Security
Logging and monitoring
Rate-limiting
Authentication and authorization
Summary
4
API Life Cycle
Design
Implementation
Release
Maintenance
Summary

Part 2: Designing an API Product
5
Elements of API Product Design
Technical requirements
Ideation
Strategy
Definition
Validation
Specification
Summary
6
Identifying an API Strategy
The meaning of strategy
Stakeholders
Business objectives
Personas
Behaviors
Summary
7
Defining and Validating an API Design
API capabilities

Use case analysis
Functional requirements
Integration needs
Security and access control
Compliance with laws and regulations
Documentation
API mock
Prototyping an API integration with a UI
Design iterations
Summary
8
Specifying an API
Choosing the type of API to build
Different types of APIs
API specification formats
OpenAPI
IDL (protocol buffers)
GraphQL
WSDL
AsyncAPI
Creating a machine-readable API definition
Following API governance rules
API design
API life cycle management
Summary

Part 3: Implementing an API Product
9
Development Techniques
Prototyping an API
Choosing a programming language and framework
Factors to consider
Popular languages for building APIs
Node.js
Python
Ruby
Java
Go
Rust
Comparing programming languages
Generating server code from a specification
Generating server code using Postman
Generating server code using OpenAPI Generator
Summary
10
API Security
What is API security?
Security testing
Authentication

API key management
Token management
Authorization
RBAC
OAuth scopes
Summary
11
API Testing
Contract testing
Performance testing
Acceptance testing
Summary
12
API Quality Assurance
Defining QA
Test planning and execution
Behavioral testing
Regression testing
API monitoring
Summary

Part 4: Releasing an API Product
13
Deploying the API
Continuous integration
API versioning
Incremental API versioning
Semantic API versioning
Calendar-based API versioning
Choosing an API gateway
Summary
14
Observing API Behavior
API usage analytics
Application performance monitoring
User feedback
Aggregating and categorizing feedback
Acting on feedback
Scaling user feedback
Summary
15
Distribution Channels
What is API distribution?

Pricing strategy
API portal
Community
Marketplaces
Documentation
Summary

Part 5: Maintaining an API Product
16
User Support
Helping users get their jobs done
Support channels
Prioritizing bugs and feature requests
Summary
17
API Versioning
Managing multiple API versions
Breaking changes
Communicating changes
Summary
18
Planning for API Retirement
When should you retire an API?
Communicating API retirement
API product retrospective
Summary
Index

Preface
Building an API Product is a comprehensive guide that ranges from the fundamentals of APIs and
their inner workings to mastering the steps involved in building successful API products. With this
book, you will be able to confidently and effectively create cutting-edge API products that excel in
today’s competitive market.

Who this book is for
This is a book that helps product managers and software developers navigate the world of APIs to
build programmable products. You don’t have to be an experienced professional to learn from this
book, as long as you have a basic knowledge of internet technologies and an understanding of how
users interact with a product.

What this book covers
Chapter 1, What Are APIs?, introduces you to API fundamentals, origins, and types such as REST,
gRPC, AMQP, and MQTT.
Chapter 2, API User Experience, explores how the API user experience is vital, second-degree
experience, and the impact of friction on success.
Chapter 3, API as a Product, outlines an API as a standalone product, emphasizing business value,
monetization options, support, documentation, and crucial security.
Chapter 4, API Life Cycle, provides an overview of the API life cycle stages, covering design,
implementation, release, and maintenance, offering an opinionated approach to API product
management.
Chapter 5, Elements of API Product Design, introduces you to the key API product design stages,
connecting ideation, strategy, definition, validation, and specification, paving the way for an in-depth
exploration.
Chapter 6, Identifying an API Strategy, analyses the strategy stage of API design, emphasizing
identifying stakeholders, determining business objectives, and understanding user personas and
behaviors.
Chapter 7, Defining and Validating an API Design, covers the techniques for defining and validating
API design, starting with strategy-derived information and exploring API mocks, UI integration, and
stakeholder iteration.
Chapter 8, Specifying an API, guides you on how to select an API architectural type based on
behaviors and capabilities, refining the definition with constraints and industry practices and creating
a machine-readable representation with governance rules.
Chapter 9, Development Techniques, offers a beginner-friendly guide to API development, covering
language and framework selection, code generation from specifications, prototyping, and extending
with business logic,
Chapter 10, API Security, explores API security, emphasizing its importance, distinguishing between
authentication and authorization, and introducing a security testing technique called fuzzing.
Chapter 11, API Testing, introduces you to API testing methods, covering contract testing to ensure
specification compliance, performance testing execution, and the connection of acceptance testing to
user personas.

Chapter 12, API Quality Assurance, covers API quality assurance, introducing behavioral testing to
validate against identified behaviors and setting up API monitors for periodic testing.
Chapter 13, Deploying the API, provides an overview of the API deployment process, covering
continuous integration, agility, automated testing, deployment, and API gateway trade-offs.
Chapter 14, Observing API Behavior, introduces you to API usage analytics, APM, and user
feedback analysis to identify and measure important metrics, usage patterns, and behavior.
Chapter 15, Distribution Channels, covers API distribution strategies, including pricing, API portals,
marketplace listing, and documentation options to enhance user activation.
Chapter 16, User Support, delves into ways to ensure user success with an API, covering support
channels, forums, and prioritizing bug fixes and feature requests from user feedback.
Chapter 17, API Versioning, explores techniques for managing multiple API versions, handling
breaking changes effectively, and communicating changes to users using machine-readable methods.
Chapter 18, Planning API Retirement, discusses API retirement, covering its definition,
considerations, and communication to users and conducting a retrospective to document what you
have learned from the process.
Download the example code files
You can download the example code files for this book from GitHub at
https://github.com/PacktPublishing/Building-an-API-Product. If there’s an update to the code, it will
be updated in the 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.
Code in text: 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: “Mount
the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”
A block of code is set as follows:
html, body, #map {
height: 100%;
margin: 0;

padding: 0
}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items
are set in bold:
[default]
exten => s,1,Dial(Zap/1|30)
exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)
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 instance, words
in menus or dialog boxes appear in bold. Here is an example: “Select System info from the
Administration panel.”
TIPS OR IMPORTANT NOTES
Appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at
customercare@packtpub.com and mention the book title in the subject of your message.
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/support/errata and fill in the form.
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
copyright@packtpub.com 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.
Share Your Thoughts
Once you’ve read Building an API Product, we’d love to hear your thoughts! Please click here to go
straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering
excellent quality content.
Download a free PDF copy of this book
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical
books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free
content in your inbox daily
Follow these simple steps to get the benefits:
1. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781837630448
2. Submit your proof of purchase
3. That’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:The API Product
This part provides a comprehensive guide to API development and management, beginning with
fundamental concepts, types, and origins, followed by a focus on user experience and the significance
of the API as a standalone product. It then delves into the API life cycle stages, covering design,
implementation, release, and maintenance, with an opinionated approach for effective API product
management.
In this part, you’ll find the following chapters:
Chapter 1, What Are APIs?
Chapter 2, API User Experience
Chapter 3, API-as-a-Product
Chapter 4, API Life Cycle

1
What Are APIs?
APIs are the most powerful technology available today. While the API acronym can be deceitfully
simple, the concept it describes offers infinite possibilities. Welcome to the world of APIs, where
you’ll learn how to build an API product. Your first step in this expedition is to first learn what an
API is. In this chapter, you will understand the nature of APIs, looking back to their origins. You’ll
also get to know which technologies and tools are available for you to use.
The chapter begins by exploring different types of networks, such as the internet, and how APIs work
on them. You will then be guided through the history of APIs. You’ll see how APIs came to life and
understand how certain concepts in use today were born. Finally, you’ll see that there are different
technologies and tools that you can use to build an API product from scratch.
By the end of this chapter, you will know that APIs can exist on different types of networks. You will
understand what those networks are and what the most appropriate one for your API product is. You
will also know that there are synchronous and asynchronous APIs and what those terms mean. Most
importantly, you will know how to pick the right type of API and tools to build your API.
In this chapter, we’re going to cover the following main topics:
The history of APIs
This section gives you an overview of the different types of APIs that exist. APIs are split between
local and remote, and then by the protocols that they adhere to. You’ll start by understanding what an
API is at a high level and why it’s so important. Then, you’ll dive into the different types of APIs.
Let’s get started.
Application programming interfaces, or APIs, allow applications to be used programmatically.
They create an interface—a layer of abstraction—that opens applications to interactions from the
outside. The interface has the goal of standardizing any connection to the application. Suppose you
think about an interface as a common boundary between two entities. In that case, an API is a way to
let an application communicate with other entities in a programmatic fashion.

This type of interaction is what you can call an integration. Integrating different applications, or
different parts of the same application, lets you build products by putting together pieces that are
ready to be used. Instead of creating all the features of a product from scratch, you can utilize
functionality that is already available in the form of an API. That alone is a powerful tool to use.
Creating a product by using APIs can be done in a fraction of the time it would take if you develop all
the features yourself. That happens because you can reuse pieces of functionality that are
standardized and well understood. Those pieces of functionality can be a whole product, a single
feature, or a subset of a product represented by a selection of features. Different types of APIs
provide different types of interactions, as you’re about to learn.
Local APIs
Local interfaces are the most used type of API, even if they’re often seen as invisible. All the
applications that run on a device need to communicate with the hardware. Applications interact with
the device via local APIs. They offer the advantage of providing a standard method of programming
the device to behave according to what users want. POSIX is one such standard created by the IEEE
Computer Society. It stands for Portable Operating System Interface, and its goal is to establish a
layer of communication that is standard across different operating systems. Another similar standard
is the Single UNIX Specification (SUS). macOS, a popular operating system developed by Apple
Inc., is considered partly compliant with POSIX and fully compliant with the SUS. This means that
anyone that interacts with macOS knows that it follows certain rules and conventions that have been
standardized. In theory, an application that is built to run on macOS could also run on other systems
that are compliant with the same standards.
Another way of introducing a standardized local layer of communication is by using common
software libraries. Even if a system doesn’t follow a full standard, some of its parts can use
standardized libraries. Java offers a popular set of libraries and APIs that can be used across systems.
The programming language was created by Sun Microsystems—acquired by Oracle Corporation—
and has been used on almost all operating systems. Java fully embodies the goal of standardizing how
applications interact. Its slogan is Write once, run anywhere, and it symbolizes the importance that its
creators give to standardized interfaces. Java’s versatility is enormous. You can use Java to create
mobile applications that run on Android devices, desktop applications, and everything in between.
By now, it’s clear that operating systems’ standards and libraries offer a way of interacting with the
lowest layers of computing devices. Another form of abstraction that encapsulates reusability at a
higher level is available through software modules. Most modern scripting programming languages
have the ability to create and use modules. Modular software development has become a popular way

of building applications. Modules provide functionality that is ready to be used and increase the
speed at which applications are built.
A widespread module system exists for the JavaScript programming language. Its name is npm, the
Node Package Manager. Its authors claim that npm is the world’s largest software registry, with
over one million modules available to be used by anyone. According to GitHub, JavaScript is the
number one used programming language at the time of writing. In fact, JavaScript has been in the
first position for the last eight years at least. Because npm is used by applications written in
JavaScript, it’s the most used module system.
Other module systems exist for different programming languages, and they all share that they want to
facilitate the reuse of functionality and increase the speed of developing software. Python, the second
most popular programming language, has PyPI, the Python Package Index. The third most popular
programming language, Java, also has its package system, Maven. There are all kinds of modules
ready for anyone to use on their applications. The point is that anyone is free to create and publish
modules and also to reuse modules that other people have published. Hence, a vast ecosystem of
modular software development keeps growing.
While local interfaces deal with the interaction between different parts of a local system, some of
those parts let you communicate with the outside world. Communication with remote systems is also
abstracted and standardized in the form of APIs. Read on to learn more about the different remote
APIs and how they can enhance the features of an application.
Remote APIs
Most people think of APIs as a way to interact with software that is running remotely. They tend to
ignore all the local interfaces that you’ve read about before—not because local APIs aren’t important,
but because they feel invisible. The opposite happens with remote APIs. Instead of being invisible,
remote APIs feel like they’re the most critical part of an application. The act of starting a connection
to a system that is running on a different part of a computer network feels like something worth
paying attention to. Remote connectivity can be split according to the type of network being used.
Let’s focus on local area networks (LANs) and wide area networks (WANs) because that’s where
most APIs operate.
LANs connect devices that are physically in the same location. The types of applications that exist on
a LAN are meant to be accessed exclusively by devices that are connected to the same network. APIs
that operate on LANs are typically focused on supporting specific classes of applications and not on
providing generic services to consumers. In other words, LAN APIs offer a way for devices to

connect to applications running on the same network. As with local APIs, here, the goal is to
standardize how the same type of applications communicate on LANs.
Databases are one type of application that is widely used in local networks. The ODBC standard was
created to standardize communication between applications and databases. ODBC stands for Open
Database Connectivity and is a standard API for accessing databases. Applications that use ODBC
can be ported across different database systems without having to be rewritten. You can, for instance,
develop a warehouse stock application that uses the MySQL database system. Suppose that, at some
point, you decide to switch to Oracle or some other database system. You don’t have to rewrite your
application as long as the database system supports ODBC. In the same way, if you decide to change
the implementation of your application to a different programming language, you don’t have to
change the database system. As long as the programming language supports ODBC, you know that
you’ll be able to interact with your database.
Printing is another popular activity on local networks. As you would expect, there are APIs that
standardize the communication between printers and other devices in the same LAN. One such API is
the Line Printer Remote protocol, or LPR. This protocol lets you interact with a printer,
programming it to print documents and even changing the configuration options of the target printer.
Even though printing happens primarily in LANs, it’s a type of application that can also be carried
out across the internet. To make communication with printers work easily outside LANs, there is a
remote API called Internet Printing Protocol, or IPP. According to Michael Sweet from Apple Inc.,
“at least 98% of all printers sold since 2010 support IPP." It became so popular because it offers
features such as authentication, access control, and encryption of data transmitted to the printer. And
it’s not the only API that operates on the internet, as you’ll see if you keep reading.
When you hear the term API, you immediately think about services that run on the internet. That’s
because wide access to networked services helped popularize the creation of APIs. Externalizing
features of an application feels natural in an environment where all services are connected to the
same network. Many times, you can even confuse internet APIs with the services that they expose.
We often talk about the API as the offering rather than the interface. That indicates that the internet
has contributed to the fragmentation of the types of APIs that are available. There are API types that
are best suited for reading data while other types are better used for synchronously storing
information, and there are types that work well to asynchronously share information about events.
Let’s start by exploring API types that let you easily read data from a remote server on the internet.
You can say that the simplest way to read data remotely is to directly access a document. However,
you would only call that an API if there were some degree of programmability involved. In other
words, when you’re directly retrieving a document, you’re not sending any parameters to an API. To

make it programmable, there has to be something on the server that interprets the request parameters
and changes the returned output based on what is being requested. A remote procedure call, or
RPC, is an example of a type of API that lets the requester send parameters to a server and, in return,
receive information. In the same way that you can read information with it, you can also use it to
store information on a server. In that case, you’re sending parameters along with the information that
you want to store. Depending on the size of the data—what you call an API payload—you can
choose what type of API and which technology to use.
As a rule of thumb, anything that happens on the internet works better with short-lived connections.
The internet is an open network. Connections between different points on the internet can change
without notice, and that can affect the quality of communication. Communicating asynchronously is
also an option. There are types of APIs that focus specifically on letting you share information in an
asynchronous way. Usually, these are used for sharing information about events, but also for
receiving the result of long-running operations. You make a request that you know is going to take a
long time to finish. When the request is completed by the server, it will share the result with you. If
availability is what matters the most, then you decide the type of API based on what is reliable most
of the time. Many APIs end up running on top of the web because it’s the most widely used protocol,
and you accept it as having a high resilience. In fact, web APIs are what you’ll be working on most of
the time when you’re building API products.
Web APIs are a type of API that uses the internet and web-specific protocols to communicate. In the
same way that the remote APIs that you’ve read about before make remote resources appear as local,
web APIs offer the same functionality for resources available on the web. On the web, it’s a common
approach to identify the supported media types that can be transferred from the server to the client.
That is also the case for web APIs. Two of the most used media types are the Extensible Markup
Language, or XML, and the JavaScript Object Notation, or JSON. These media types can be
easily used and interpreted by API client software. The big advantage of web APIs over other types of
remote APIs is the features that the web offers. Just by using the web, you have access to content
caching, or the ability to temporarily store responses that can be reused between requests. You also
have access to authentication mechanisms that don’t require any specific implementation. Finally,
you become part of a vast ecosystem of server and client tools that are widely available for anyone to
use.
While there are different types of APIs, you’re reading this book most probably because you’re
interested in web APIs. As you’ve seen before, to most people, APIs are a synonym for something
such as a programmable interface running on the web. The API that you’ll build will probably run on
the web as well, so let’s use that as a guide throughout the rest of the book. Keeping in mind that

there are several types of APIs, let’s focus on how to build web APIs. To get there, let’s look now at
how APIs came to exist and how they have been evolving.
The history of APIs
By now, you already know that there are different types of APIs that you can use depending on what
you’re trying to achieve. It’s important to know how APIs were created and which events were the
key contributors to their evolution. Learning how we got to where we are now is the first step to
understanding how to build successful products on top of APIs.
To understand how APIs were invented, let’s go back in time to circa 1950. At that time, computing
was just getting started, and the first known mention of a software module was made by Herman
Goldstine and John von Neumann. The authors were referring to local APIs in the form of modules
or, as they called it, “subroutines.” In their Report on the Mathematical and Logical Aspects of an
Electronic Computing Instrument from 1947, they explain what a subroutine is. To the authors, a
subroutine is a special kind of routine—a set of program instructions that can be reused. They
describe that a subroutine has the purpose of being substituted inside any existing routine. It’s clear
that the authors were focusing on reusability, as you’ve read before in this chapter. In fact, from then
on, APIs have been used as a way to reduce the amount of programming required to build an
application.
However, the work of Goldstine and von Neumann was purely theoretical and couldn’t be put into
practice at that time. It was only when the Electronic Delay Storage Automatic Calculator, or
EDSAC, was created that software modules were actually used. In 1951, Maurice Wilkes, the creator
of EDSAC, was inspired by the work of Goldstine and von Neumann. Wilkes introduced the use of
modules as a way to reuse functionality and make it easier to write programs from scratch. Wilkes,
jointly with Wheeler and Gill, describes how subroutines could be used in their book The
Preparation of Programs for an Electronic Digital Computer. In this, they explain that with a library
of subroutines, it should be simple to program sophisticated calculations. You’d only have to write a
master routine that, in turn, calls the various subroutines where the different calculations are
executed.
Still, the first time the term “application program interface” (notice that the word used isn’t
“programming”) appeared was probably in the Data Structures and Techniques for Remote Computer
Graphics paper published in 1968. In this, its authors, Ira Walter Cotton and Frank S. Greatorex,
notice the importance of the reusability of code in the context of hardware replacement. The paper
mentions that even if you change the hardware, a “consistent application program interface could be
maintained.”

Since then, the concept of reusability through the isolation of code to create APIs has been evolving.
While initially, the focus was on APIs that could be used locally within an operating system, at a later
stage, remote APIs were explored, most notably web APIs. In 2000, Roy Fielding published an
intriguing Ph.D. dissertation titled Architectural Styles and the Design of Network-based Software
Architecture. In it, Fielding analyzes the differences between local APIs—which are based on
libraries or modules—and remote APIs. The author calls local APIs library-based and remote APIs
network-based. While local APIs have the goal of offering entry points to code that can be reused,
remote APIs aim to enable application interactions. According to Fielding, the only restriction that
remote APIs have is the ability to read and write to the network where they operate. Let’s continue
our exploration through the history of APIs. Keep reading to understand how one of the most popular
operating systems is in the origins of web APIs.
Unix
Web APIs originated with the Unix operating system and its way of letting different applications—or
processes—communicate with each other. In reality, Unix is not a single operating system. It’s a
group of operating systems with the same root: AT&T Unix. The first version was created in the
1970s by Ken Thompson and Dennis Ritchie at the Bell Labs research center. AT&T decided to
license Unix to other companies after the first version was released to the public in 1973. The
licensing of Unix made it—and all its variants—one of the most used types of operating systems of
all time. One of those variants, the Sun Microsystems Solaris operating system, has contributed the
most to the history of web APIs.
From its inception, Unix has been recognized for its modular structure, where individual processes
are created with simplicity in mind and aimed at seamless collaboration. This approach, referred to as
the Unix philosophy, has become one of the primary reasons for its immense success and a crucial
factor in the evolution of web APIs. Brian Kernighan, one of the developers of the Unix operating
system, described interoperability during a demo performed in 1982:

“(...) you can take a bunch of programs and stick them together end-to-end so the data simply
flows from the one on the left to the one on the right.”
Inter-process communication, or IPC, is a system integrated into Unix that enables the transfer of
messages between various processes. IPC is a collection of APIs that allows developers to coordinate
the execution of concurrent processes. The IPC framework offers multiple forms of communication,
including pipes, message queues, semaphores, shared memory, and sockets, to accommodate the
needs of diverse applications. However, it’s worth noting that, except for sockets, all other
communication methods are confined to processes running on the same server, limiting their scope
and functionality. It’s precisely with sockets that network APIs gained traction and different use cases
emerged.
Network APIs
Sun Microsystems leveraged the functionality of network sockets to introduce a method of
communicating with remote processes, known as RPC. The concept of RPC was first introduced in
the 1980s as part of Sun’s Network File System (NFS) project and adhered to the calling
conventions used in Unix and the C programming language. It rapidly gained popularity due to its
ability to enable any running application to send a request over a network to another application,
which would then respond with the result of the requested operation. The messages and responses are
encoded using the External Data Representation format, or XDR, which provides a standard
format understood by both the producer and consumer. The RPC protocol offers the capability to
deliver messages with XDR payloads through either the User Datagram Protocol (UDP) or the
Transmission Control Protocol (TCP), thereby providing compatibility with different network
types. While UDP is a protocol more oriented toward performance, TCP offers more reliability in
situations where the quality of the network is questionable.
The journey from the first implementations of RPC to its official publication as an Internet
Engineering Task Force (IETF) Request for Comments, or RFC, took about a decade. The RPC
protocol was first published as RFC 1831 in 1995 and underwent various transformations through
subsequent versions until it reached its latest form in 2009, as described in RFC 5531. That year, Sun
Microsystems changed the RPC license to the widely used three-clause BSD, which made it available
for free to anyone. Today, most variations of the Unix operating system provide some form of native
RPC support. At the same time, Microsoft Windows also offers official support for the protocol
through its Services for UNIX (SFU) software package. Other operating systems offer RPC
compatibility with various implementations for programming languages such as C, C++, Java, and
.NET.

Despite RPC’s widespread popularity and reputation as a lean and straightforward protocol to
implement and use, there may be better choices for heterogeneous network environments. One of the
primary issues with RPC has to do with the passing of parameters and the interpretation of data
between clients and servers that are written in different programming languages. Although RPC relies
on the XDR format to describe payloads, the definition of data types can vary between operating
systems and programming languages, resulting in the misinterpretation of information. This has led
to the rise of other protocols that provide an abstraction layer for messages and parameters.
The concept of service-oriented architecture, or SOA, emerged as the prevailing standard for
facilitating collaboration among applications operating in heterogeneous environments. Around the
same period, various internet-based public services were gaining popularity, with the World Wide
Web (WWW) particularly attracting the attention of a wider audience outside the academic
community.
The web
In 1989, Tim Berners-Lee, an English scientist, created the WWW. Since then, it has become the
primary means of accessing information and communicating online. During its early years, the web
comprised simple interconnected blocks of information, known as web pages, which could be
accessed to view information. These web pages were manually updated by webmasters, who were
responsible for maintaining the content. With the rise of commercial web initiatives, various services
were developed to allow individuals to upload and share personal information such as photos, blogs,
and other forms of multimedia. This led to the creation of desktop applications that enabled users to
interact with online services more efficiently. Initially, these applications were used to download
information, but eventually, they allowed users to upload content to the web.
The way desktop content-creation applications communicated with the newly launched web services
gave rise to what we now refer to as web APIs. One such early example was Flickr, a widely used
photo-sharing service that allowed developers to interact with it via a web API. The API enabled
developers to perform a range of tasks such as uploading, downloading, listing, and searching photos
from a single user account or across the entire service. Business applications such as Salesforce also
benefited from what web APIs had to offer. In fact, Salesforce was probably the first modern web
API to be launched and used.
On the more closed side of the software industry, other protocols started to emerge, with the goal of
simplifying the life of developers and integration designers. One such protocol gained significant
popularity because of its natural integration with existing Microsoft tools. It was the Simple Object
Access Protocol, or, in short, SOAP. Microsoft promoted SOAP, and it became the number one way

to integrate its different products. SOAP became popular outside of the Microsoft world with support
from several programming languages and operating systems. For some time, SOAP was seen as the
successor of RPC and the way to connect all kinds of business applications. You can see a simplified
illustration of a SOAP request here:
Figure 1.1 – A simplified illustration of a SOAP request
Around the same time, another protocol was being developed to utilize as many features of HTTP as
possible and better meet the needs of web services. This resulted in the creation of the
Representational State Transfer Protocol, commonly known as REST. Its creator was Roy

Fielding, who you already know from before in this chapter. In his Ph.D. dissertation, Fielding not
only described how remote APIs should operate but also invented REST:
REST is a hybrid style derived from several of the network-based architectural styles (...) and
combined with additional constraints that define a uniform connector interface.
The network-based architectural styles that Fielding refers to include cache and client-server, two
things that are familiar in web interactions. Compared to SOAP, REST is much easier to understand
and process and a natural winner on the open web because it doesn’t need as many rules to operate as
SOAP does. You can see a simple illustration of this protocol here:
Figure 1.2 – A simplified illustration of a REST request where data is sent from a client to a server to create (POST),
replace (PUT), or modify (PATCH) a resource
However, because it’s more open, it doesn’t offer the level of control and security that SOAP offers.
While that might not be an issue with non-critical applications, it is a must for business-related APIs.
Because of that, another protocol was created. This time, the goal was to increase control over what
was transmitted so that the information could be validated in a reproducible way.
Google’s Remote Procedure Call, or, in short, gRPC, was born in 2015. It started to be used by
almost all of Google’s open web APIs. gRPC works on top of HTTP/2, the second version of HTTP,
offering, among other things, low latency and the ability to stream data between servers and clients.
However, the big advantage of gRPC over other protocols is that it uses a strict interface description
language. Protocol Buffers, or Protobuf, is the format used by gRPC to describe the interface and
messages shared between clients and servers. Unlike other languages, Protobuf is binary and offers
high security and performance. However, Protobuf is oriented toward providing a way to remotely
execute code that is available on the API server.

At around the same time, the need for openly querying large amounts of data started to grow.
Facebook, a popular social network, pioneered the use of graph databases. It was clear that REST
wasn’t the best way to access data that was always changing, and gRPC wasn’t the answer either. So,
GraphQL, a data query and manipulation language, was created. Compared to other API
architectures, its main difference is that it allows clients to define the shape of the data that they want
to query—that, too, at runtime, in a dynamic way. Even though it doesn’t sound like much, this was a
big deal because of two factors. On the one hand, it allowed bandwidth-conscious clients—such as
mobile phones—to retrieve just the data they needed, saving precious bandwidth. On the other hand,
it opened the available data graph to clients, allowing them to openly query all existing data through
the API.
Read on to learn more about the most relevant technologies and protocols that you can use to build
API products. It would help if you didn’t restrict yourself to using web APIs. Instead, you should
build the API product that best reflects the needs of your users, and to do that, the more knowledge
you have about what’s available, the better. This section offers detailed information about the
different API technologies, the communication protocols, and the tools that are considered important
to someone building an API product. Let’s start by splitting the knowledge into the areas of
communication protocols, implementation technologies, and tools.
Communication protocols
Among the available communication protocols, the ones that are most overlooked are the ones that
run on local networks. Usually, local network protocols help Internet of Things (IoT) devices and
applications communicate. These protocols use a low amount of power to preserve the batteries of the
devices that they support. Among IoT protocols, you have one called Zigbee. This protocol is an
IEEE 802.15.4-based specification and is used by popular home automation companies. Philips Hue,
for instance, uses Zigbee to power communication between lamps and other devices. Indesit, a house
appliance manufacturer, uses Zigbee to adjust its washing machines’ cycle starting time according to
the price of electricity. Yale, one of the oldest locks companies, uses Zigbee to control its smart door
locks. Samsung, a technology manufacturer, uses Zigbee to let you control and monitor its smart
refrigerators. If you’re thinking about building an API product that interacts with a local device, then
a protocol similar to Zigbee might be a good choice.
Even though Zigbee has been gaining popularity, the fragmentation of local connectivity protocols is
something to pay attention to. For that reason, a group of organizations created a new standard called

Matter. Among the organizations behind Matter is, in fact, Zigbee. Matter’s goal is to help new
product builders adopt a communications standard that they know will work with a vast array of
products.
Let’s now focus on communication protocols that operate on the internet. While local network
protocols solve challenges related to power consumption and interoperability, internet protocols are
more focused on the reliability of communication. Reliability, in this case, means the ability to
consistently transport information between a user and a server. Users unknowingly engage with
servers while they’re performing their online activities. The protocol behind most online activities is
the Hypertext Transport Protocol, or HTTP. From a user perspective, it’s as if the information is
right in front of you, being displayed on the screen of the device that you’re using. From a
communication perspective, information is traveling across the world using the internet to arrive at
your device and then be displayed. HTTP is behind that communication and translates what users
request into commands that are sent to servers. The web is powered mostly by HTTP, and when you
refer to APIs, most of the time what you’re referring to are web APIs.
In summary, HTTP is the protocol behind most of the available APIs. HTTP is a protocol that works
in a synchronous way. In other words, when users request something, the information is sent to a
server, and the client waits until a response is available. The response might become available almost
immediately, in which case the interaction feels like it’s happening immediately. Or, in some
situations, it might take longer for a server to produce a response. Other protocols have been created
to handle situations where the user doesn’t need a response immediately or the user doesn’t want to
wait for a response to become available. Those protocols handle what is called asynchronous
communication.
Among the available asynchronous ways of communicating, you have the Advanced Message
Queuing Protocol, or AMQP. This is a protocol that is primarily focused on handling queues of
messages. A queue of messages is a group of pieces of information that are stored in a specific order.
Each message is picked from the queue and processed one after another. Messages can contain any
information and can be used in a variety of patterns that enable multiple kinds of products. You can
have messaging patterns that let users perform a command asynchronously. Other patterns are used to
let users receive notifications on their devices. There are even patterns that let a server broadcast
messages to a group of users without having to connect to each user individually. The important thing
to retain about AMQP is that it lets you create interactions that don’t require an immediate response
from the server.
Another asynchronous protocol that is popular among IoT products is Message Queuing Telemetry
Transport, or MQTT. This protocol focuses on being lightweight in the information it needs to let

messages flow from a server to a client. MQTT was built to be as simple as possible and enable low-
powered devices to subscribe to information that servers make available. Before, you saw how IoT
devices can communicate synchronously inside a local network using Zigbee. In this case, MQTT
enables those devices to send and receive information to other devices in an asynchronous way.
Implementation technologies
Now that you know what the available communication protocols are, let’s see which technologies
you can use to build API products. Starting with local networks, the technologies that you can use
either work on top of protocols such as Zigbee or something at a higher level such as HTTP or
MQTT.
Let’s start with Zigbee. The Zigbee protocol describes three types of devices that can operate on the
network. You can build a Zigbee coordinator, a router, or an end device. The Zigbee coordinator
manages communication between other types of devices. It can also serve as a bridge between Zigbee
and other types of networks, such as the internet. The Zigbee router is responsible for making sure
that the information flow reaches all the devices present in the network. Finally, Zigbee end devices
are the final nodes in the network. You can build on top of the Zigbee protocol by using—or asking
your engineering team to use—one of the available frameworks. The Connectivity Standards
Alliance (CSA), formerly known as the Zigbee Alliance, offers documentation and pointers to
implement solutions for Zigbee and also for the Matter protocol. Operating systems such as Tizen
offer direct support for Zigbee to applications built to run on it.
Moving into internet technologies, let’s look at what you can build on top of HTTP. Anything that
runs on top of HTTP is understood as “the web.” Fortunately, there are plenty of technologies and
approaches to building web APIs. From frameworks to API specifications, you have a lot to choose
from. There may be many solutions because the web itself is the most used communication platform.
To begin with, most programming languages offer a way of building a web API from scratch. For
instance, Node.js, a popular programming language, has the Express.js framework. Python, another
language, offers Flask and FastAPI. And there are other options for languages such as Java or PHP.
You can pick the language and framework that best fits your needs and where you or the engineers
that work with you feel more comfortable.
To specify the API that you’re building, you also have different options. In this case, depending on
the type of web API that you’re building, you have different specification standards. OpenAPI is the
preferred specification for REST APIs. While REST restricts your API consumers to the resources
and operations that you make available, you can offer more generic access through GraphQL.
Essentially, GraphQL lets your API consumers access the data that you are exposing as a graph. In

other words, you don’t have to provide all the queries and operations beforehand because consumers
can navigate the data itself. If you’re concerned about performance and data validation, you can use
the gRPC specification. With this approach, you have a specific format for the information that is
shared between consumers and servers, making the communication stricter than with the REST
approach. All these technologies provide a synchronous communication solution. Read on to learn
how you can build asynchronous APIs.
If the API that you’re building doesn’t require an immediate response, or if the operation that you
offer takes too long to process, then you can think of offering an asynchronous solution.
Asynchronous APIs usually make use of two communication channels. One of the channels is used
by the API consumer to send information to the server. The API consumer uses this channel to
execute an operation on the server or to request certain information. The second channel is used by
the server to communicate the result of the request back to the consumer. Those two channels can
coexist on the same type of network or can use totally different approaches. One example of a second
channel that runs on top of HTTP is called Webhooks.
With Webhooks, you ask the API consumer to provide a way to receive a request from the server.
When the server has information to be shared with the consumer, it uses the Webhook URL to push
the available data. The consumer then receives the request and the information that they were waiting
for. Another way of building an asynchronous API on top of the web is to use something called
WebSockets. In this case, the API will be used by web browsers to communicate with the server. The
goal is to open a direct communication channel that can be used by both the browser and the server to
send information in both directions. This will allow the server to send information to the browser
asynchronously. As an example, this is how some solutions, such as browser notifications, are
implemented.
If we now move to other asynchronous protocols, there are different products that you can use.
RabbitMQ is a product that provides an asynchronous communication broker that runs on the AMQP
protocol. Mosquitto is another broker that in turn runs on MQTT. Another product that provides
asynchronous messaging solutions is Kafka. Even though Kafka uses its own communication
protocol and message format, it’s worth mentioning because it’s one of the most used asynchronous
solutions.
Tools
By now, you know about the protocols, formats, and technologies that are available to help you build
an API product. Continue reading to learn about the tools that you can use to get your API up and
running. You have tools that let you design and define how your API will behave. Other tools help

you validate your API and offer a mockup. There are also tools that convert your API definition into
running code that can be deployed to a running server. Whichever tool you use, remember that it
doesn’t replace your knowledge. You should be able to do things on your own by understanding the
principles and the theory behind your actions. Let’s start by looking at API design tools. These are
usually web applications that help you create an API definition document. These are important to you
because they help you build your API product during the first stages of the process.
One of the most popular API design tools is Postman. This is a web and desktop application that can
be used individually or by different members of a team to collaborate. Postman offers an interface
that lets you create API definitions and automatically runs validation checks to make sure that your
API follows industry best practices. With Postman, you can create an API mock from your API
definition. You can share a link to the mock with your potential customers and use it for validating
your API design. Your API clients can use the mock to try making requests to the API and seeing
what it looks like before you actually release any product.
Another tool in the area of API design is Stoplight. The company offers a web and desktop
application that lets you design and document your API. Among its features is the possibility of
generating and customizing API portals to offer onboarding and documentation to developers. API
design is the strong offering of Stoplight. It offers a unique visual approach to designing an API.
Instead of typing your OpenAPI definition into a text editor, you can visually configure how your
API will behave.
Swagger is probably the oldest API design tool still available. It offers a web application that lets you
design your API by writing its OpenAPI definition. Even though it uses a text editor, it automatically
renders the result of what you’re typing. You can interactively write your API definition and see the
results immediately as API documentation. That’s an interesting approach because it gives you the
perspective of what your API consumers will view.
Another area that is interesting to you is API documentation. API documentation gives you the ability
to explain to your users what your API does and how they can use it. There are several tools in this
area, ranging from simple documentation generators to more sophisticated API portals. In fact, all the
aforementioned API design tools also allow you to publish API documentation. However, there are
other tools that are more focused on API documentation.
One such tool is ReadMe. This is a web application that lets you build interactive API documentation.
Anyone that accesses your API documentation will be able to interact with the API and engage with
you, or your support team, if needed. It also lets you, the API owner, interact with your users by
sharing updates whenever something changes. With ReadMe, you don’t have to install anything as
the tool hosts the whole documentation.

Another tool that lets you build your API portal is Apiable. This lets you create your API
documentation and goes further by letting you manage the signup and onboarding process. Apiable
also lets you create what it calls “API products.” This feature lets you define signup processes and
subscription plans for your API. Apiable manages the process so that you can focus on building and
maintaining your API.
If you prefer to use an open source tool that you can run on your machine, you can look at Redoc.
This is a tool that generates documentation from an OpenAPI definition document. Redoc follows a
popular three-panel page layout with features such as a search bar and API request and response
examples. You can install it on your machine and run it every time you update your OpenAPI
definition.
The tools that I presented here are meant to be examples of what is available. Keep in mind that tools
change—what’s important is that you stay updated with what exists. No tool can replace your own
knowledge and how you’re able to build and maintain your API. However, having the right tools at
hand makes your job much easier and more pleasant.
Summary
By now, you have a fair understanding of what APIs are, how they evolved, and how their history is
connected to the history of computing and the internet. You also know which technologies and tools
you can use to build your API product. Let’s look back at all the things you learned in this chapter.
You started by understanding the concept of API as a way to connect different pieces of software
together, independently of their location or the communication protocol that they’re using. Then, you
dived into local APIs, which run locally on the device and help the operating system and the
applications that run on top of it communicate with each other. After that, you learned the difference
between these local APIs and the remote ones that run on networks. Then, you walked through the
history of APIs, seeing that, since the beginning, emphasis has been placed on the reusability of
software. You saw how different people, such as von Neumann, Fielding, and Berners-Lee,
influenced how APIs work and what they do. From there, you went through the existing technologies,
protocols, and tools that are available for you to build an API product.
These are some of the concepts that you’ve learned in this chapter:
An API is a programmable way of interacting with an application
APIs offer reusable functionality that reduces the time it takes to build new applications
Software modules and programming language libraries can be considered APIs
APIs exist on different types of networks, not just the web

Different communication protocols provide different features to the APIs that run on them
The following are things to take into account when choosing between a synchronous and an
asynchronous API approach:
The features that different API standards such as RPC, REST, gRPC, and GraphQL offer
Different tools can help get your job done and help you with API design, documentation, validation, testing, and deployment
Thank you for reading this chapter. In the next chapter, you’ll focus on API user experience or API
UX. You’ll be able to understand how to identify the users of your API and how to make sure they
have the best possible experience. Keep reading to learn more about developer experience, API
friction, and other topics related to API UX.

2
API User Experience
A product is nothing without its users, and user experience is at the core of building and managing a
product that users love. To effectively measure and improve your API user experience, or API UX,
you must start by identifying those users. This chapter explores the different types of users and how
they interact with APIs. You’ll be able to see the diversity of ways in which APIs can be consumed.
You’ll also learn what second-degree user experience is and how it can contribute to the success of an
API product.
This chapter begins by exploring the top industries where APIs are consumed the most. We will then
describe the notion of API personas and the top professional roles in API usage. This chapter dives
deep into developers and how their experience of using an API affects their success. You’ll then see
how the end user experience is tied to APIs and how you can improve it. Finally, we will explore the
idea of API friction and how it negatively influences the user experience and the success of the API
product.
By reading this chapter, you will know what the different types of API users are and their jobs and
challenges. You will understand that developers are the most significant group of API users. You will
learn that to have a successful API product, you need to offer a good developer experience. You will
also know that API Design can influence the experience of users of applications created on top of an
API. By the end of this chapter, you will be able to identify the factors that contribute to API friction
and how to mitigate them.
This chapter dives deep into the following topics:
Who uses APIs?
Developer experience
Second-degree user experience
API friction
Who uses APIs?
APIs aren’t used exclusively by developers. More than half of API users have roles unrelated to
software development. According to the 2022 State of the API Report published by Postman, Inc., a
survey of about 40,000 API professionals revealed that the most representative non-developer roles
sum up more than 20%. Another similar report published by RapidAPI corroborates this by showing

that only 80% of the respondents have a developer role. Additionally, API users come from a variety
of industries. While technology companies occupy the largest share of API users, other industries,
such as education, healthcare, and banking, represent about 20%, according to the reports mentioned
previously.
APIs are not something reserved for developers and the technology industry. It’s interesting that most
people building APIs still focus on developers as their only users. Instead, as an API builder, you
should start exploring the other roles that can also be users of your API. By looking at a single type of
user, you might miss out on an important share of your potential user base. Keep reading to learn
more about how APIs are used across different industries and how each of the roles uses APIs in their
day-to-day activities.
Industries
Several professionals in different roles from a vast list of industries use APIs daily. To better
understand how they use APIs, let’s first focus on a short list of the most representative industries.
The industries that you should look closer at, ordered from the one with the least amount of API users
to the one with the most, are education, healthcare, banking, and technology. All these industries
represent at least 4% of global API usage, with the highest share of more than 50% of global API
usage coming from the technology sector. There are undoubtedly other exciting industries. However,
those are less representative than the four we’re covering here:

Figure 2.1 – Global API usage breakdown by top industries, according to 2022 surveys by Postman and RapidAPI
Education
When you mention the word “education,” most people picture schools, teachers, and students in
uniforms. However, the education industry is much larger than that. Yes, schools are a part of the
education industry. Other segments of the education sector include colleges, universities, corporate
training companies, and additional specialized training services. Altogether, those segments employ
about 5% of the global workforce. That’s about 170 million people working in the education industry,
representing 4% of the total API usage. If you think about it, it’s already a sizeable market. Of course,
not all education professionals will become API users. However, it’s a ceiling to look at when
thinking about your API users.
Education organizations use software – and APIs – in many different ways. The list includes
authoring software that helps teachers produce instructional material, reference software such as
dictionaries and encyclopedias, proofreading and plagiarism software, and communication tools to
help parents and teachers exchange information. As you can imagine, there are already APIs

operating in this space. The Oxford Dictionary offers an API that you can use to retrieve definitions
of words, synonyms, antonyms, or even sentences where a particular word is being used. Smodin has
an API that checks a given piece of content for plagiarism. This type of tool is gaining popularity
among education professionals to verify whether student assignments are original. Additio is a
company that offers a platform that helps, among others, teachers, students, and parents communicate
effectively. All these APIs can be used directly. However, that’s not how they’re usually accessed in
the context of an educational organization.
Most schools and other educational organizations use what are called “learning environments” in the
industry. These are the basis of how schools organize themselves and how all the participants interact.
Among those environments, the ones that are the most popular are Google Classroom, Blackboard
Learn, and Moodle. These learning management systems, or LMSes, focus on helping users
manage aspects of the education program. The features they offer include course management,
curricula editing, and attendance monitoring. On top of those specific features, all these systems
provide a vast number of integrations in the form of plugins, enhancements, or “applications” that run
inside them. And those integrations work because both the learning environments and the third-party
software have APIs. By using these learning environments, education professionals and students can
interact with APIs indirectly. Another industry where APIs are used mostly indirectly is healthcare.
Continue reading to learn more about it.
Healthcare
The healthcare industry is probably the one with the highest chances of surviving. We all, at some
point in our lives, will need some type of health assistance. The healthcare sector employs about 2%
of the global labor force or around 65 million people, contributing to 4% of the total API usage.
Those people are split across different types of healthcare businesses, such as hospitals, health
insurance companies, and health equipment. These three segments are attractive because they have to
share large amounts of data about patients. Privacy is vital in any business sector. However,
healthcare is significantly regulated, so no unwanted patient information is leaked.
The regulation is so tight that there are standards to help companies operate. One of those standards
is the Fast Healthcare Interoperability Resources (FHIR) standard. It was created by HL7, a non-
profit standards development organization. With FHIR, healthcare information can be shared securely
and efficiently between operators. FHIR aims to be modular so that information can be produced and
consumed granularly. It supports different data formats, such as XML and JSON, and follows
existing web standards. The FHIR standard identifies resources that are common in the healthcare
industry. Other standards exist to extend and provide more detail to the common resources that FHIR
defines. Among those standards is the United States Core Data for Interoperability (USCDI). This
standard defines a set of attributes that should be exposed using FHIR at the request of healthcare

patients. Those attributes include things such as clinical notes about the patient, information about
medication, vital signs, and identification of implantable devices, such as pacemakers. Failure to
comply with the existing regulations by not following the correct standards might incur sanctions.
Therefore, before building an API in the healthcare sector, it’s crucial to have a clear understanding
of the regulations and standards.
Let’s see how healthcare companies use APIs to share information. One type of information-sharing
happens between hospitals and health insurance companies. The most simple form of API exists to
help hospitals share medical bills with health insurance companies. Other, more sophisticated use
cases include obtaining a patient’s medical record to calculate insurance costs, retrieving family
medical history to understand the probability of diseases occurring, or calculating health scores based
on a patient’s visits to healthcare providers. Eligible is a company that offers an insurance billing
API, which is used by healthcare applications. OneRecord provides an API that lets operators access
a patient’s medical records, and 1upHealth provides a health history API. Other types of sophisticated
capabilities are also being exposed through APIs. Infermedica, for instance, offers an API that
generates a diagnostic based on a patient’s symptoms.
Wallgreens has an API that lets healthcare companies order refills of medical prescriptions. The
power of all these APIs is that they can be integrated into the management software that hospitals and
other healthcare providers use. By integrating with healthcare APIs, the management software can be
extended with added features. Banking is another area where the ability to externalize features is
essential. Keep reading to see how banks use APIs.
Banking
According to the World Bank’s Global Findex Database, in 2021, 76% of the world’s population had
at least one bank account. Banking is a sector that has grown steadily and touched all sectors of
society. Estimates indicate that the banking industry employs about 1% of the global workforce or
around 35 million people. While 1% seems like a low value, it powers an industry with an estimated
market capitalization of over seven trillion US dollars. It also contributes 11% to the API usage of all
sectors – all this without mentioning that digital banking has grown steadily. And digital banking is
what people use when they access their bank accounts through the web or a mobile application.
While web and mobile access to bank accounts constitute a large share of banking API use, the story
doesn’t end there. Far from it. The greatest use of banking APIs happens between banks and other
financial institutions. Because dealing with money and other financial assets is seen as a critical
activity, bank communications are highly regulated. And, as you’ve noticed with the healthcare
sector, whenever there are regulations, standards emerge to fill the void. In the case of banking, there
are two primary standards in use: the Open Banking Standard, which was born out of necessity after

the European Union revised the Payment Services Directive (PSD2) regulation, and the Banking
Industry Architecture Network (BIAN). The Open Banking Standard was born in the European
Union as a way to unify the PSD2 regulation. It aims to provide guidelines to banking implementors
through a set of API specifications and security profiles. The API specifications include payment
initiation, both domestic and international, confirmation of funds, recurring payments, and event
notifications. It also provides resources for third parties that wish to build mobile and web
applications targeting banking customers. The BIAN went beyond Open Banking and offered an
ecosystem of different players from the banking sector. Together, they have been offered guides,
standards, and enhanced API specifications that conform to international regulations.
Without Open Banking, it wouldn’t be possible for people like yourself to build products that interact
with banking information. One way that APIs are used in banking is to allow applications to access –
and manipulate – consumer information. In 2023, the number of applications that enhance what
banks offer has been growing. Goin, for example, is a product that helps people save money and
spend better by connecting to their existing bank accounts. Belvo provides a layer of abstraction to let
you quickly initiate payments to multiple banks. Brex is a banking service oriented at companies that
offers integration with several invoicing and management applications. All these use cases wouldn’t
be possible without API specifications like the ones promoted by Open Banking and the BIAN. The
number of scenarios where banks interoperate with each other has been growing. And at the same
time, the technology to support those scenarios has also evolved. Read on to understand how the
technology sector not only controls most of the existing APIs but is also their most significant
consumer.
Technology
Whenever you think about APIs, you immediately picture technology professionals creating
integrations and connecting applications. The technology sector has the most significant share of API
consumers. With an estimated 60 million people working in the industry worldwide, or about 2% of
the global labor force, technology is the driver of most other business sectors. The technology
industry involves companies and professionals working on areas that range from physical
communication infrastructure to web start-ups. With the fast pace of digitalization of businesses
worldwide, it’s easy to understand that software is behind almost everything we do. A famous venture
capitalist, Marc Andreessen, once said that “software is eating the world.” What he meant is that
software removes all the barriers that once existed in everyday transactions. Software can do what
used to be done by people in a faster, easier, and cheaper way. And that is primarily because of the
existence of APIs.
The technology sector mainly uses APIs to build software that other business industries use.
However, it also uses APIs to address its own needs. Technology companies use different types of

APIs to manage, control, and maintain the creation and deployment of software. Software
development, for instance, usually involves the release of different versions with improvements or
fixes over time. The management of those releases is generally done with version control systems. A
popular version control system, Git, lets software developers store their work in a repository and
distribute the code to other team members. Deploying applications to servers that run on the cloud is
also done with the help of APIs. Amazon Web Services (AWS) offers a vast set of APIs that lets
developers provision servers and deploy their applications. New Relic is an observability product that
lets developers analyze the performance of their applications by sending telemetry data using an API.
All these services have, as their primary customer, the technology industry. In other cases, APIs are
built so that different business sectors can use them.
One of the business sectors that consumes a big part of the work of technology professionals is the
writing industry. In particular, web writing professionals take advantage of all the APIs that exist to
connect various services. Think about blogging software and all the integrations that they provide, or
all the tools that surround social media services. WordPress, a popular blogging platform, lists more
than 10,000 plugins in its “API” section alone. There are plugins related to marketing and selling
products online. Other plugins interact with event management services to let writers display relevant
information on their blogs, while others allow writers to interact with emailing services to send
messages to their readers periodically. Buffer, one of the most used social media sharing services, can
interact with nine different channels. You, as a writer, can share your content across a multitude of
social media services all because of APIs. And writing is just one example of a business sector that
depends on technology to grow. Writers are one type of professionals that often use APIs without
even realizing it. However, other professionals engage with APIs directly. Read on to learn what
those groups of professionals, or personas, are and discover their attributes.
Personas
Now that you’ve seen that APIs are used in several business industries, let’s focus on the types of API
consumers. According to Postman’s 2022 State of the API Report, other than developers, the more
relevant API consumers are business analysts, product managers, students and teachers, software
architects, and quality engineers. Together, these groups of professionals constitute 21% of API
consumers. As a comparison, developers – full-stack, backend, and frontend – constitute 49% of API
consumers.
You can call these consumers personas because each represents a group of people with similar
characteristics. According to the Nielsen Norman Group, there are three types of personas:
lightweight, qualitative, and statistical. In this section, you’ll focus on the lightweight – or proto- –

personas. They’re called proto-personas because they represent a prototype that you can expand from
during your process. The proto-personas that you’ll read about have been crafted from my own
experience. The way to describe each persona is to identify the attributes that are relevant to you
when building an API. You usually care about each persona’s jobs, challenges, and tools. During your
API Design process, you’re encouraged to perform qualitative persona analysis by conducting user
interviews. For now, let’s analyze the personas that are the most expected to interact with APIs.
Business analysts
A business analyst is someone that helps organizations manage and improve their internal processes.
Analysts obtain and validate business requirements and map them to existing technology. They
identify and improve processes while following business orientation. With this information, you can
now identify the generic tasks related to API consumption. Business analysts analyze and interpret
the usage of tools from existing data, automate the interaction between different tools to improve
processes, and obtain summarized information from usage data to present to business leaders. The
challenges that a business analyst faces are proving hypotheses to business stakeholders based on
existing data and presenting findings from datasets using standard business tools. Business analysts
use tools such as spreadsheets, slide presentations, document editors, and data access software during
their work. They also engage with the tools that they’re analyzing. They consume APIs both directly
and indirectly. Direct API consumption happens when they need to access data and system
information to help them identify patterns. Indirect API access occurs whenever they set up
integrations between two or more existing tools. Finally, through their findings and
recommendations, business analysts can influence an organization to build specific APIs.
Product managers
While a business analyst works inside an organization and improves its way of working, a product
manager works with potential customers that are not part of the organization. Most of the work of a
product manager is around interacting with prospects to identify their needs and translating that
evidence into product specifications. Product managers are also owners of the product roadmap, a
timeline of all the features proposed to be included in the product. They also spend time presenting
the evidence and the roadmap to internal business stakeholders, promoting their ideas of what should
be included in the product. Finally, product managers are communicators and often participate in
writing engagements where they promote the product and any new features. From an API
perspective, product managers analyze existing product usage to identify patterns and present
summarized findings to business stakeholders. They engage with existing and potential customers
using communication and social media services and publish product promotional information using
blogs and social media services. Product managers face the challenges of proving their product
feature hypotheses based on their findings, communicating efficiently with users using different

channels, and convincing business leaders that their product proposals are worthy of investment.
They use tools such as analytics software, spreadsheets, data manipulation software, presentation
applications, and blogging and social media services. Most of the tasks involve some form of indirect
API consumption. However, product managers also use APIs directly when interacting with data
systems. More importantly, product managers are also behind the creation of the APIs that are used
by all the other personas.
Students and teachers
Both students and teachers are a part of the education industry, which you learned about in this
chapter. Students and teachers are two different groups of people with specific attributes. However,
for this examination, we will put them in the same group. To do that, let’s focus on the tasks that both
students and teachers engage in. They communicate with each other using learning environments and
the integrations that are available with other systems. They search for and obtain information about
the topics that they study and teach, and they use software to monitor their daily activities. Their
challenges are finding the information they need from existing web services and presenting it in a
meaningful way. The tools they use include web browsers, document-editing applications,
spreadsheets, digital whiteboards, and slide presentation applications. From an API-centric
perspective, they’re also responsible for creating new concepts and ideas and experimenting with
new technology. Take, for example, Roy Fielding, the creator of REST, who you learned about in
Chapter 1. Fielding shared his ideas about REST in his Ph.D. dissertation. He was a student learning
about new API concepts and experimenting. From that learning and experimentation, a new API
architecture was born. Speaking of architecture, keep reading to see how software architects interact
with APIs.
Software architects
The software architect’s role can be seen as a hybrid between the disciplines of design and
engineering. Software architects work on understanding what the business goals are, translating that
information into actionable technical principles, and designing software that meets the criteria.
Software architects can also develop the software themselves or lead a team of developers to do that.
Their tasks are then somehow similar to the ones of business analysts but with a focus on software
development. They analyze and interpret how people interact with existing software within an
organization and design any improvements they feel are needed. To do that, they document the
creation of new software and present their proposals to business stakeholders. Software architects’
challenges are convincing business leaders of new software design approaches, identifying patterns in
software usage to back their hypotheses, and communicating software development plans to team
members. The tools that software architects use include code editors, diagram applications, document
editors, and slide presentation applications.

Random documents with unrelated
content Scribd suggests to you:

the banks of the rivers of Sarawak—the Batang, Lupar, Saribas,
Krian, and Rejang.
The Dyak is of rather greater stature than that of the Malay,
though he is considerably shorter than the average European. The
men are well-proportioned, but slightly built. Their form suggests
activity, speed, and endurance rather than great strength, and these
are the qualities most required by dwellers in the jungle. Their
movements are easy and graceful, and their carriage erect. The
women are generally smaller than the men. They have neat figures,
and are bright, cheerful, and good-looking in their youth, but they
age very soon.
The colour of their skin varies considerably, not so much between
one tribe and another as in different parts of the country. Generally
speaking, those who reside in the interior of the country, on the
banks of the upper reaches of the rivers, are fairer than those who
live nearer the sea. This may be due to the deeper shade afforded
by old jungle, and the bathing in and drinking of the water of the
clear, gravel-bedded streams. Their colour varies from a dark bronze
to a light brown, with a tinge of yellow. Their eyes are black or dark
brown, clear and bright, with quick intelligence and good temper.
Their mouths are generally ill-shapen and disfigured by excessive
chewing of sireh and betel-nut, a habit much indulged in by both
men and women.
In dress great alterations have resulted from foreign influence,
and the Dyaks who live near the towns wear the trousers and coat
of civilized races, but the original style still prevails in the up-country
villages.

Three Typical Dyaks
The man on the right is using a seat mat made of
the skin of an animal. Sometimes these mats are
made of split cane. The Dyak, in his wanderings in
the jungle, has often to sit on prickly grass or sharp
stones, and a seat mat is a useful part of his attire.
Love of finery is inherent in the young Dyak. The old men are
often very shabbily dressed, but the young are more particular. The
ordinary male attire consists of a sirat, or waist-cloth, a labong, or
headkerchief, and a tikai buret, or seat-mat. The waist-cloth is made

of the soft inner bark of a tree, or more frequently of some red or
blue cotton cloth. This is one yard wide, and from eight to eighteen
feet long, and is twisted round and round their waists, and pulled up
tight between the thighs, one end hanging down in front and the
other behind. Sometimes this waist-cloth is woven by the Dyak
women, and then the end that hangs down in front has an elaborate
pattern woven into it. Their head-dress is either a bright-coloured
headkerchief, or else a small cap of woven cane, in which feathers
and other ornaments are often stuck. The tikai buret, or seat-mat, is
made either of the skin of some animal or of cane matting. Its edges
are decorated with red and white cloth, and with beads or buttons.
Besides these articles of apparel the men sometimes wear a
sleeveless jacket, or klambi. These are often woven by the Dyak
women, either from yarn spun from cotton of their own growing or
from imported yarn of a finer texture. More often in the present day
they are made of cloth of European manufacture. The patterns of
the Dyak-woven klambi are various, but those of a particular type
can only be worn by men who have succeeded in securing a human
head when on the warpath. The lower edge of this jacket is
ornamented with beads, shells, and buttons, and bordered by a
fringe.
In addition to the attire already mentioned, the men have
sometimes a dandong, or shawl, which is thrown over the shoulders.
The ornaments worn on the arms and legs are brass rings, which
vary among the Dyaks of different districts. Armlets made from sea-
shells are very much in favour among some inland tribes. The young
men generally wear their hair long, cut in a fringe in front, and
either hanging down loose behind, or tucked into their caps.
Tattooing is practised by most of the Dyaks in a greater or less
degree. It is confined to the male sex, who often have little patterns
tattooed on the forehead, throat-apple, shoulders, or chest.
The dress of the women consists of a petticoat (kain), drawn
tightly round the waist and reaching to the knee, and in addition a
klambi, or jacket, worn when out of doors. For ornaments the

women wear finger-rings, necklaces, earrings, and bracelets, and
often a girdle formed of silver coins, or of silver or brass chain.
Round the stomach are wound long strips of coloured cane. Among
some tribes a peculiar corset, called the rawai, is worn by the
women. This is made of small brass rings strung closely together on
hoops of rattan, which are connected with one another inside by a
network of cane. A few of these hoops are made larger so as to
hang loose over the hips. The series that encase the waist, stomach,
and chest fit very close. This corset must be very uncomfortable, as
the wearer can hardly bend the body at all, especially when it is
worn right up to and covering the breasts, as it is done by some
young women who can afford such extravagance.
The hair is worn long, and tied in a knot at the back of the head.
Some of the women have beautiful raven black hair of great length.
Wavy or curly hair is seldom seen.
The teeth are often blackened, as black teeth are considered a
sign of beauty. The blackening is done by taking a piece of old
cocoanut-shell or of certain woods, and holding it over a hot fire
until a black resinous juice exudes. This juice is collected, and while
still warm the teeth are coated with it. The front teeth are also
frequently filed to a point, and this gives their face a curious dog-like
appearance. Sometimes the teeth are filed concavely in front, or else
the front teeth are filed down till almost level with the gums.
Another curious way of treating the front teeth is to drill a hole in
the middle of each tooth, and fix in it a brass stud. I was once
present when this operation was in progress. The man lay down with
a piece of soft wood between his teeth, and the “dentist” bored a
hole in one of his front teeth. The agony the patient endured must
have been very great, judging by the look on his face and his
occasional bodily contortions. The next thing was to insert the end
of a pointed brass wire, which was then filed off, leaving a short
piece in the tooth; a small hammer was used to fix this in tightly,
and, lastly, a little more filing was done to smooth the surface of the
brass stud. I am told the process is so painful that it is not often a

man can bear to have more than one or two teeth operated on at a
time.
The Dyaks do not like beards, and much prefer a smooth face. In
the whole course of my Dyak experience I have only met with one
bearded man. The universal absence of hair upon the face, on the
chest, and under the arm-pits might lead one to suppose that it was
a natural deficiency. But this is not the case at all, as old men and
chronic invalids, who by reason of age or infirmity have ceased to
care about their personal appearance, have often chins covered with
a bristly growth. The absence of hair on the face and elsewhere is
due to systematic depilation. The looking-glass and tweezers are
often seen in the hands of the young men, and they devote every
spare moment to the plucking out of stray hairs. Kapu, or quicklime,
which is one of the constituents of betel-nut mixture chewed by the
Dyaks, is often rubbed into the skin to destroy the vitality of the
hair-follicles.
Among some tribes it is the fashion for both men and women to
shave the eyebrows and pull out the eyelashes, and this gives their
faces a staring, vacant expression. I have often tried to convince
them of the foolishness of trying to improve upon nature in this way,
and pointed out that both eyebrows and eyelashes are a protection
to the eyes from dust and glare. But my remarks have made little
impression on them. Among the Dyaks, as elsewhere, fashions die
hard.
The Sea Dyak language is practically a dialect of Malay which is
spoken more or less over all Polynesia. It is not nearly so copious as
other Malayan languages, but the Dyaks do not scruple to use Malay
words in their conversation when necessary. The Dyak language is
particularly weak in expressing abstract ideas. What the mind cannot
grasp the tongue is not likely to express. I believe there is only one
word—rindu—to express all the different varieties of love. On the
other hand, the language is rich in words expressing the common
actions of daily life. There are many words to express the different
ways of carrying anything; one word for carrying in the hand,

another for carrying on the back, and another for carrying on the
shoulder.
There are several words in Dyak which resemble Malay words of
the same meaning, the difference being that the Malay suffix an is
changed into ai. Thus, the Malay word makan (to eat) becomes
makai in Dyak, and jalan (to walk) becomes jalai. There are some
words exactly the same in both languages, and these are for the
most part simple substantives, such as rumah (house), laki
(husband), bini (wife). Verbs, however, commonly differ, though
expressing simple necessary actions. Thus, the Malay word for “to
drink” is minum, the Dyak word is ngirup; the Malay for “to eat” is
makan, and the Dyak empa as well as makai.
It is not surprising that there should be many words in Dyak not
known to the Malays. Though derived from the same parent tongue,
the Dyak language has developed independently by contact with
other races.
There are many tribes that talk the Sea Dyak language. The
Sabuyaus living on the coast and at Lundu, the Balaus of the Batang
Lupar and elsewhere, the dwellers on the Skrang and Saribas Rivers,
as well as the Kanowit and Katibas branches of the Rejang River, all
speak it, with slight modifications. There can be no doubt that all
these tribes are descended from the same parent stock.
The difference of dialect between the different tribes is often a
source of great amusement, and I remember well taking some
Saribas boys, who had been some time in my school at Banting, on
a visit to their people. We sat in the long veranda of the Dyak house,
and I noticed that as they spoke to their relatives and friends there
were shrieks of laughter and great merriment. The reason of this
was that the boys had unconsciously picked up the Balau dialect
during their stay at Banting, and their manner of speaking amused
their Saribas friends exceedingly.

Dyak village house—Tanju—Ruai—Bilik—Sadau—Human heads—Valuable jars—
Paddy-planting—Men’s work—Women’s work—House-building—Boat-building
—Kadjangs—Dyak tools—Bliong—Duku—Weaving—Plaiting mats and basket-
making—Hunting—Traps—Fishing—Spoon-bait—Casting-net—Tuba-fishing—
Crocodile-catching.
Among the Dyaks a whole village, consisting of some twenty or
thirty families, or even more, live together under one roof. This
village house is built on piles made of hard wood, which raise the
floor from six to twelve feet above the ground. The ascent is made
by a notched trunk or log, which serves as a ladder; one is fixed at
each end of the house. The length of this house varies according to
the number of families inhabiting it; but as the rooms occupied by
the different families are built on the same plan and by a
combination of labour, the whole presents a uniform and regular
appearance.
The roof and outside walls are thatched with the leaves of the
nipa palm, which are first made into attap. These are made by
doubling the leaves over a stick about six feet long, each leaf
overlapping the other, and sewn down with split cane or reeds.
These attap are arranged in rows, each attap overlapping the one
beneath it, and thus forming a roof which keeps off the rain and
sun, and lasts for three or four years.
The long Dyak village house is built in a straight line, and consists
of a long uncovered veranda, which is called the tanju. The paddy is
put on the tanju to be dried by the sun before it is pounded to get
rid of its husk and convert it into rice. Here also the clothes and a
variety of other things are hung out to dry. The family whetstone
and dye vat are kept under the eaves of the roof, and the men
sharpen their tools and the women do their dyeing on the tanju. The
flooring of this part of the house is generally made of bilian, or iron-
wood, so as to stand exposure to the weather.
Next to the tanju comes the covered veranda, or ruai. This also
stretches the whole length of the house, and the floor is made of

bamboo, or nibong (a kind of palm), split into laths and tied down
with rattan or cane.
This ruai, or public hall, is generally about twenty feet wide, and
as it stretches the whole length of the house without any partition, it
is a cool and pleasant place, and is much frequented by men and
women for conversation and indoor pursuits. Here the women often
do their work—the weaving of cloth or the plaiting of mats. Here,
too, the men chop up the firewood, or even make boats, if not of
too great a size. This long ruai is a public place open to all comers,
and used as a road by travellers, who climb up the ladder at one
end, walk through the whole length of the house, and go down the
ladder at the other end. The floor is carpeted with thick and heavy
mats, made of cane interlaced with narrow strips of beaten bark.
Over these are spread other mats of finer texture for visitors to sit
upon.
The length of this covered veranda depends upon the number of
families living in the house, and these range from three or four to
forty or fifty.
Each family has its own portion of this ruai, and in each there is a
small fireplace, which consists of a slab of stone, at which the men
warm themselves, when they get up, as they usually do, in the chill
of the early morning before the sun has risen.
Over this fireplace hangs the most valuable ornament in the eyes
of the Dyak, the bunch of human heads. These are the heads
obtained when on the warpath by various members of the family—
dead and living—and are handed down from father to son as the
most precious heirlooms—more precious, indeed, than the ancient
jars which the Dyaks prize so highly.
The posts in this public covered veranda are often adorned with
the horns of deer and the tusks of wild boars—trophies of the chase.
The empty sheaths of swords are suspended on these horns or from
wooden hooks, while the naked blades are placed in racks overhead.

On one side of this long public hall is a row of doors. Each of
these leads into a separate room, or bilik, which is occupied by a
family. The doors open outwards, and each is closed by means of a
heavy weight secured to a thong fastened to the inside. If the room
be unusually large, it may have two doors for the sake of
convenience.
Dyak Making a Blow-pipe
He is seen here shaping the outside of the blow-
pipe. The hole is bored while the wood is about six
inches in diameter, and it is then pared down to about
two inches.

Dyak Village House in course of Construction
This picture shows the arrangement of pillars and
rafters of a Dyak house. The floor nearest the earth is
divided into the long open veranda and the rooms in
which the different families live. Above this is the loft,
where the paddy is stored away. Part of the roof in
the picture has been covered with palm-leaf thatch.
This room serves several purposes. It serves as a kitchen, and in
one corner there is a fireplace where the food is cooked. This
fireplace is set against the wall of the veranda, and resembles an
open cupboard. The lowest shelf rests on the floor, and is boarded
all round and filled with clay. This forms the fireplace, and is
furnished with a few stones upon which the pots are set for cooking.
The shelf immediately above the fireplace is set apart for smoking
fish. The shelves above are filled with firewood, which is thoroughly
dried by the smoke and ready for use. As the smoke from the wood
fire is not conducted through the roof by any kind of chimney, it
spreads itself through the loft, and blackens the beams and rafters
of the roof.
This room also serves as a dining-room. When the food is cooked,
mats are spread here, and the inmates squat on the floor to eat
their meal. There is no furniture, the floor serving the double
purpose of table and chairs.
This bilik also serves as a bedroom. At night the mats for sleeping
on are spread out here, and the mosquito-curtains hung up.
There is no window to let in the air and light, but a portion of the
roof is so constructed that it can be raised a foot or two, and kept
open by means of a stick.
Round the three sides of this room are ranged the treasured
valuables of the Dyaks—old jars, some of which are of great value,
and brass gongs, and guns. Their cups and plates are hung up in
rows flat against the walls. The flooring is the same as that of the
veranda, and is made of split palm or bamboo tied down with cane.
The floor is swept after a fashion, the refuse falling through the

flooring to the ground underneath. But the room is stuffy, and not
such a pleasant place as the open veranda. The pigs and poultry
occupy the waste space under the house.
From the bilik there is a ladder which leads to an upper room, or
loft (sadau), where they keep their tools and store their paddy. If the
family be a large one, the young unmarried girls sleep in this loft,
the boys and young men sleeping outside in the veranda.
Both men and women are industrious and hard-working. With
regard to the paddy-planting on the hills, the work is divided
between the men and women in the following manner. The men cut
down the jungle where the paddy is to be planted. When the timber
and shrubs have been burnt, the men and women plant the grain.
The roots of the trees are left in the ground. The men walk in front,
with a long heavy staff in the right hand of each, and make holes in
the ground about a foot apart. The women walk behind them and
throw a few grains of seed in each hole.
When the paddy has grown a little, the ground has to be carefully
weeded; this work is done by the women. When the crop is ripe,
both men and women do the reaping. They walk between the rows
of standing grain, and with a sharp, oddly-shaped little knife they cut
off the heads one by one, and place them in their baskets, which are
tied in front of them. The carrying home of the paddy thus reaped is
mostly done by the men, who can carry very heavy loads on their
backs, though the women help in this to some extent. The next
thing is to separate the grain from the little tiny stems to which it is
still attached. This is done by the men. The grain is put on a large
square sieve of rattan fixed between four posts in the veranda of the
Dyak house, and the men tread on it and press it through the sieve.
The paddy that falls through is taken and stored in the loft in large
round bins made of bark.

Dyak Girls Pounding Rice
After the paddy has been passed through the
husking mill it is pounded out in wooden mortars.
Here are two girls at work. Each has her right foot in
the upper part of the mortar to kick back any grains
of paddy that may be likely to fall out.
A Husking Mill (Kisar)

After the paddy is dried and
before it is pounded, it is
generally passed through a
husking mill made in two parts—
the lower half having a stem in
the middle which fits into the
upper part, which is hollow. The
paddy is put into a cavity in the
upper half, and a man or woman
seizes the handles and works the
upper half to the right and left
alternately. The paddy drips
through on to the mat on which
this husking mill is placed.
Drying Paddy
Before it is possible to rid the
paddy of its husk and convert it
into rice, it has to be dried in the
sun. Here a woman is seen
spreading out the paddy on a
mat with her hands. She is on the
outside veranda of the Dyak
house (tanju). The long pole over

her head is used by her to drive
away the fowls and birds who
may come to eat the paddy put
out to dry.
When rice is wanted for food, the paddy is dried, and then
pounded by the women in wooden mortars, with pestles five feet
long. As a rule two or three women each use their pestles at one
mortar, which is cut out of the trunk of a tree. I have seen as many
as six girls using their pestles in quick succession at one mortar. In
this way the grain is freed from husk, and is made ready for food.
Each family farms its own piece of land. Much of such work as
cutting down the jungle and planting is done by a combination of
labour, several families agreeing to work for each other in turn. By
this means all the planting on the land belonging to a particular
family is done in one day, and all the grain ripens at the same time.
When the Dyaks wish to abandon an old habitation in favour of a
new one, a general meeting of the inhabitants is held to consider the
matter, and the desirability of building a new house is fully
discussed. Sometimes it happens that some families do not agree
with the wishes of the majority, and these families split off and join
another house. If a move be decided on, a few experienced men are
deputed to choose a site, and to report on its adaptability. There are
several matters to be taken into account. The site must be for
preference on rising ground, and be near a good supply of water.
There must also be some jungle near, where the inmates can get
their firewood, and there must be large tracts of land not far away
where they can plant their paddy.
When the new house has to be built on the low-lying, marshy
ground in the lower reaches of the river, the choice is not difficult. All
that is necessary is to choose a part of the river where the current is
not very strong. But in the hill country it is not easy to find a site
where the ground is fairly level, and can accommodate a large house
of thirty or forty families.

Before building on the chosen site the omen birds are consulted. If
the omens be favourable, all the men and lads turn out immediately
with axes and choppers to cut down the trees of the jungle, which
are then left to dry. Another meeting is then held to decide who is to
be the tuai, or headman, of the new house, and to settle the size
and the sequence of the rooms. The next move is to appoint a time
for all the people to meet at the site of the new village. The ground
is then cleared. All the timber is carried off, as it is considered
unfortunate to burn it. The ground is measured out for the different
rooms belonging to the different families, and pegs are put in where
the posts have to stand. A piece of bamboo is then stuck in the
ground, filled with water and covered with leaves. A spear and a
shield are placed beside it, and the whole is surrounded by a
wooden rail. The rail is to prevent the bamboo from being upset by
wild animals, and the weapons are to warn strangers not to touch it.
A few people remain to keep watch, and to make a great deal of
noise with brass gongs and drums to frighten away the evil spirits. If
in the early morning they find there is much evaporation, the place
is considered unhealthy, and is abandoned. If all be well, the
building of the house is begun. Each family must kill a fowl or a pig
before the holes for the posts can be dug, and the blood must be
smeared on the sharpened ends and sprinkled on the posts to
propitiate Pulang Gana, the tutelary deity of the earth. They begin
by making the holes for the headman’s quarters, and then work
simultaneously to left and right of it. The posts, of which there are a
great number, are about twelve inches or less in diameter, and are of
bilian or other hard wood so as not to rot in the earth. A hole four
feet deep is made to receive each post. They must be planted
carefully and firmly, for if one were to give way subsequently it
would be regarded as foreboding evil, and the house would have to
be abandoned and a new house built.
All the men combine to labour collectively until the skeleton of the
house is complete, and then every family turns its attention to its
own apartments. During the building of the house, there is a great
deal of striking of gongs and other noisy instruments to prevent any

birds of ill omen being heard. I have sometimes argued with the
Dyaks that if the warnings of the birds are to be trusted, then why
make so much noise to prevent hearing them? The Dyak’s reply to
this was that as long as they did not hear the warning, the spirits
would not be displeased at their not regarding it; so to spare
themselves the trouble of choosing another site and building another
house, they make so much noise as to drown the cries of any birds.
When the building is sufficiently advanced to receive the inmates,
they pack up their possessions and convey them to the house,
halting on the way till they have heard some favourable omen, after
which they proceed joyfully. Their belongings must not be moved
into the house before themselves, but must be taken with them
when they move into the new house.
House-building is considered the work of the men, and another
important work the men have to do is the making of boats. These
are of all sizes, from the dug-out canoe twelve feet long to the long
war-boat eighty to ninety feet in length.
The ordinary boats of the Dyaks are cut out of a single log. Some
of my schoolboys, under the guidance of the native schoolmaster,
once made a small canoe for their own use, so I saw the whole
process. A tree having a round straight stem was felled, and the
desired length of trunk cut off. The outside was then shaped with
the adze to take the desired form of a canoe. Then the inside was
hollowed out. The next thing to do was to widen the inside of this
canoe. This was done by filling the boat with water and making a
fire under it, and by fastening weights to each side. When the shell
had been sufficiently opened out, thwarts were placed inside, about
two feet from each other, to prevent the wood shrinking when the
wood dried. The stem and stern of the canoe are alike, both being
pointed and curved, and rising out of the water. The only tool used
for the making of a boat of this kind is the Dyak axe or adze
(bliong).
This is the usual type of Dyak boat, and the method of making a
smaller or larger canoe is exactly the same. Even a war-boat, ninety

feet long, is made from the trunk of one tree. In the longer boats
planks or gunwales are stitched on the sides, and the seams are
caulked so as to render the boat watertight. These boats are
covered with awnings called kadjangs, which make a very good
covering, as they are at once watertight, very light, easily adjusted,
and so flexible that if necessary each section can be rolled up and
stored in the bottom of the boat. These kadjangs are made of the
young leaves of the nipa palm. The leaves are sewn together with
split cane, each alternate leaf overlapping its neighbour on either
side, until a piece about six and a half feet square is made. This
section is made to bend in the middle crosswise, so that it can be
doubled and rolled up, or partly opened, and made to serve as a
roof. Sometimes kadjangs are made from the leaves of the Pandanus
palm.
Sea Dyaks making a Canoe
Sea Dyaks at work on a small dug-out. The tree has been felled, and the trunk
is being cut into shape and hollowed out. The Dyaks are using the native axe or
bliong, and the picture shows their method of handling it.
To propel these boats the Dyaks use paddles about three feet or
more in length. The paddle used by the steersman is larger than
those used by the others, and the women use much smaller paddles

than the men. These dug-out boats draw very little water, and are
easily handled, and may be propelled at a good pace.
In shallow streams and in the rapids up-river, the Dyaks use small
canoes, which they propel with poles, standing up in the boat to do
so.
The principal tools the Dyaks have for their work are the duku and
bliong. The duku is a short, thick sword, or, rather, chopping-knife,
about two feet in length. The blade is either curved like a Turkish
scimitar, or else quite straight. The handle is beautifully carved, and
is made of hard wood or of horn. The duku is used in war as well as
for more peaceful purposes. In the jungle it is indispensable, as
without it the Dyak would not be able to go through the thick
undergrowth which he is often obliged to penetrate. It is, moreover,
used for all purposes where a knife or chisel is used, and is a
warrior’s blade as well as a woodman’s hatchet.
The bliong is the axe the Dyaks use, and is a most excellent tool.
They forge it of European steel, which they procure in bars. In shape
it is like a small spade, about two and a half inches wide, with a
square shank. This is set in a thin handle of hard wood, at the end
of which there is a woven pocket of cane to receive it. The lower
end of this handle has a piece of light wood fixed to it to form a firm
grip for the hand. The bliong can be fixed in the handle at any
angle, and is therefore used as an axe or adze. With it the natives
make their boats, and cut planks and do much of their carpentering
work. The Dyak can cut down a great forest tree with a bliong in a
very short time.
While the work of the men is to build houses and to make boats,
the work of the women is to weave cloth and make mats.
The cloth which the women weave is of two kinds, striped and
figured. The former is made by employing successively threads of
different colours in stretching the web. This is simple enough. The
other pattern is produced by a more elaborate process. Undyed
white thread is used, and the web stretched. The woman sketches

on this the pattern which she wishes to appear on the cloth, and
carefully notes the different colours for the different parts. If, for
example, she wishes the pattern to be of three colours—blue, red,
and white—she takes up the threads of the web in little rolls of
about twenty threads, and carefully wraps a quantity of vegetable
fibre tightly round those parts which are intended to be red or white,
leaving exposed those parts which are intended to be blue. After she
has in this manner treated the whole web, she immerses it in a blue
dye made from indigo, which the Dyaks plant themselves. The dye
takes hold of the exposed portions of the threads, but is prevented
by the vegetable fibre from colouring the other parts. Thus the blue
portion of the pattern is dyed. After it has been dried, the vegetable
fibre is cut off, and the blue parts tied up, and only the portion to be
dyed red exposed, and the web put into a red dye. In this way the
red part of the pattern is obtained. By a similar method all the
colours needed are produced. The weft is of one colour, generally
light brown.
Dyak weaving is a very slow process. The woman sits on the floor,
and the threads of the weft are put through one by one. The cloth
they make is particularly strong and serviceable. The women seem
to blend the colours they use in a pleasing manner, though there is a
great sameness in the designs.

Girls Weaving
They are seated on mats on the floor. The threads are fastened to a frame,
which is kept in position by a large band that is secured to the girl’s waist, and
she can tighten or loosen the threads by leaning back or bending forward. The
threads of the weft are put through one by one from right to left and left to
right.
Mats are made either with split cane or from the outer bark of
reeds. The women are very clever at plaiting, and some of their
mats have beautiful designs.
They also make baskets of different sizes and shapes, some of
which have coloured designs worked into them.
Hunting is with the Dyaks an occasional pursuit. They live upon a
vegetable rather than upon an animal diet. But in a Dyak house
there are generally to be found one or two men who go out hunting
for wild pig or deer on any days when they are free from their usual
farm work. The Dyak dogs are small and tawny in colour, and
sagacious and clever in the jungle.

Native hunting with good dogs is easy work. The master loiters
about, and the dogs beat the jungle for themselves. When they have
found a scent, they give tongue, and soon run the animal to bay.
The master knows from the peculiar bark of the dogs if they are
keeping some animal at bay, and follows them and spears the game.
The boars are fierce and dangerous when wounded, and turn
furiously on the hunter, who often has to climb a tree to escape from
their tusks. The dogs are very useful, and by attacking the hind legs
of the animal keep making it turn round.
Deer are more easily run down than pigs, because they have not
the strength to go any great distance, especially in the hot weather.
A favourite way of catching deer is to send a man to follow the
spoor of a deer, and to find out where it lies to rest during the heat
of the day. Then large nets made of fine cane are hung around, and
the deer is driven into these by a large number of men, women, and
boys making a noise. When the deer is caught in the net, he is soon
killed.
A variety of traps are made by the Dyaks to catch birds and wild
animals. One of these traps (peti) set for killing wild pig is a
dangerous contrivance by which many Dyaks have lost their lives. It
consists of a spring formed by a stick being tied to the end of a post
and pulled apart from it. The end of this stick is armed with a sharp
bamboo spear. I have known of several men being killed by this trap,
and in Sarawak this particular trap is forbidden by the Government
to be set.
The Sea Dyaks are very expert with the rod and line, and with
them fishing is a favourite occupation. They begin fishing at an early
age. For bait they use worms or certain berries. Their hooks are
made of brass wire.
Another method of fishing is by wooden floats (pelampong),
generally cut in the form of a duck. Each has a baited hook fastened
to it, and is set swimming down the stream. The owner of these

floats drifts slowly in his canoe after them, watching, till the peculiar
motions of any of these ducks shows that a fish has been hooked.
The achar is a spoon-bait. A piece of mother-of-pearl shell or
some white metal is cut in the form of a triangle. At the apex the
line is attached, and at the base are fastened two or three hooks by
a couple of inches of line. This appliance is generally used with a rod
from the bows, and another man in the stern paddles the boat
along.
The Dyaks also have many varieties of fish-traps, which they set in
the streams and rivers. Most of these are made of split bamboo.
They also have nets of various kinds; the most popular is the jala,
or circular casting-net, loaded with leaden or iron weights in the
circumference, and with a spread sometimes of twenty feet. Great
skill is shown by the Dyak in throwing this net over a shoal of fish
which he has sighted. He casts the net in such a manner that all the
outer edge touches the water almost simultaneously. The weights
cause it to sink and close together, encompassing the fish, and the
net is drawn up by a rope attached to its centre, the other end of
which is tied to the fisherman’s left wrist. The thrower of this net
often stands on the bow of a small canoe, and shows great skill in
balancing himself. The jala is used both in fresh and salt water, and
can be thrown either from the bank of a river or by a man wading
into the sea.
But the most favourite mode of fishing among the Dyaks is with
the tuba root (Cocculus indicus). Sometimes this is done on a small
scale in some little stream. Sometimes, however, the people of
several Dyak houses arrange to have a tuba-fishing. The men,
women, and children of these houses, accompanied by their friends,
go to some river which has been previously decided upon. A fence
made by planting stakes closely together is erected from bank to
bank. In the middle of this there is an opening leading into a square
enclosure made in the same fashion, into which the fish enter when
trying to escape from the tuba into fresh water. The canoes then
proceed several hours’ journey up the river, until they get to some

place decided on beforehand. Here they stop for the night in small
booths erected on the banks of the river. The small boats are cleared
of everything in them so as to be ready for use the next day.
All the people bring with them fishing-spears and hand-nets. The
spears are of various kinds—some have only one barbed point, while
others have two or three. The shaft of the spear is made of a
straight piece of bamboo about six feet long. The spear is so made
that, when a fish is speared the head of the weapon comes out of
the socket in the bamboo; but as it is tied on to the shaft, it is
impossible for the fish to escape. Even when the fisherman throws
his spear at the fish, there is little chance of the fish escaping,
because the bamboo bears it to the surface, and it is easy for the
men to pick up the bamboo shaft and thus secure the fish.
Most of the people bring with them some tuba root, made up into
small close bundles, the thickness of a man’s wrist, and about six
inches long. Early the next morning some of the canoes are filled
with water, and the root is beaten and dipped into it. For an hour or
so fifty or more clubs beat a lively tattoo on the root bundles, as
they are held to the sides of the boats. The tuba is dipped into the
water in the boat, and wrung out from time to time. This gives the
water a white, frothy appearance like soap-suds. The Dyaks, armed
with fish-spears and hand-nets, wait in readiness in their canoes. At
a given signal the poisoned liquid is baled out into the stream, and
the canoes, after a short pause, begin to drift slowly down the
current. The fish are stupefied by the tuba, and as they rise
struggling to the surface, are speared by the Dyaks. The large fish
are thus secured amid much excitement, several canoes sometimes
making for the same spot where a large fish is seen. The women
and children join in the sport, and scoop up the smaller fish with
hand-nets. The tuba does not affect the flesh of the fish, which can
be cooked and eaten.
This form of fishing, when carried out on a large scale, is always a
great event among the Dyaks, because besides the large amount of

fish secured on these occasions, there is always a great deal of fun
and excitement, and it is looked upon as a pleasant sort of picnic.
Dyaks Returning from Tuba-fishing
In tuba fishing the juice of the tuba root is put in the water to poison it, and
cause the fish to rise stupefied to the surface, when they are secured either with
spears or by hand-nets. In the picture the men are seen taking up to the Dyak
house their fish spears and the fish they have succeeded in taking. The boats,
which are dug-outs, each made out of the trunk of a tree, are being made fast to
the bank. The large hats the men are wearing as a protection from the sun are
made of palm leaves. On the right of the picture is seen a three-pronged fish-
spear.
For superstitious reasons the Dyaks do not interfere with the
crocodile until he has shown some sign of his man-eating propensity.
If the crocodile will live at peace with him, the Dyak has no wish to
start a quarrel. If, however, the crocodile breaks the truce and kills
someone, then the Dyaks set to work to find the culprit, and keep on

catching and killing crocodiles until they find him. The Dyaks
generally wear brass ornaments, and by cutting open a dead
crocodile they can easily find out if he is the creature they wish to
punish. Sometimes as many as ten crocodiles are killed before they
manage to destroy the animal they want.
There are some men whose business it is to catch crocodiles, and
who earn their living by that means; and whenever a human being
has fallen a victim to one of these brutes, a professional crocodile
catcher is asked to help to destroy the murderer. The majority of
natives will not interfere with the reptiles, or take any part in their
capture, probably fearing that if they did anything of the kind, they
themselves may some time or other suffer for it by being attacked
by a crocodile.
The ordinary way of catching a crocodile is as follows. A piece of
hard wood about an inch in diameter and about ten inches long, is
sharpened to a point at each end. A length of plaited bark of the
baru tree, about eight feet long, is tied to a shallow notch in the
middle of this piece of wood, and a single cane or rattan, forty or
fifty feet long, is tied to the end of the bark rope, and forms a long
line. The most irresistible bait is the carcase of a monkey, though
often the body of a dog or a snake is used. The more overpowering
the stench, the greater is the probability of its being taken, as the
crocodile will only swallow putrifying flesh. When a crocodile has
fresh meat, he carries it away and hides it in some safe place until it
decomposes. This bait is securely lashed to the wooden bar, and one
of the pointed ends is tied back with a few turns of cotton to the
bark rope, bringing the bar and rope into the same straight line.
The next thing is to suspend the bait from the bough of a tree
overhanging the part of the river known to be the haunt of the
animals. The bait is hung a few feet above the high-water level, and
the rattan line is left lying on the ground, and the end of the rattan
is planted in the soil.
Several similar lines are set in different parts of the river, and
there left for days, until one of the baits is taken by a crocodile.

Attracted either by the smell or sight of the bait, some animal raises
itself from the water and snaps at the hanging bundle, the slack line
offering no resistance until the bait has been swallowed and the
brute begins to make off. Then the planted end of the line holds
sufficiently to snap the slight thread binding the pointed stick to the
bark rope. The stick thus returns to its original position, at right
angles to the line, and becomes jammed across the crocodile’s
stomach, the two sharpened points fixing themselves into the flesh.
Next morning the trappers search for the missing traps, and
seldom fail to find the coils of floating rotan, or cane, on the surface
of some deep pool at no great distance from the place where they
were set. A firm but gentle pull soon brings the crocodile to the
surface, and if he be a big one, he is brought ashore, though smaller
specimens are put directly into the boat, and made fast there.
Sometimes the cotton holding the bar to the line fails to snap. In
that case the crocodile, becoming suspicious of the long line
attached to what he has swallowed, manages to disgorge the bait
and unopened hook in the jungle, where it is sometimes found. But
should the cotton snap and the bar fix itself in the animal’s inside,
nothing can save the brute.
The formidable teeth of the crocodile are not able to bite through
the rope attached to the bait, because the baru fibres of which the
rope is made get between his pointed teeth, and this bark rope
holds no matter how much the fibres get separated.
Professional crocodile catchers are supposed to possess some
wonderful power over the animals which enables them to land them
and handle them without trouble. I have seen a man land a large
crocodile on the bank by simply pulling gently at the line. But this is
not surprising, as from the crocodile’s point of view there is nothing
else to do but follow, when every pull, however gentle, causes
considerable pain.
The rest of the proceeding is more remarkable. The animal is
addressed in eulogistic language and beguiled, so the natives say,

into offering no resistance. He is called a “rajah amongst animals,”
and he is told that he has come on a friendly visit, and must behave
accordingly. First the trapper ties up its jaws—not a very difficult
thing to do. The next thing he does appears to me not very safe.
Still speaking as before in high-flown language, he tells the crocodile
that he has brought rings for his fingers, and he binds the hind-legs
fast behind the beast’s back, so taking away from him his grip on the
ground, and consequently his ability to use his tail. When one
remembers what a sudden swing of the muscular tail means, one
cannot help admiring the man who coolly approaches a large
crocodile for the purpose of tying his hind-legs. Finally the fore-legs
are tied in the same way over the animal’s back. A stout pole is
passed under the bound legs, and the animal is carried away. He is
taken to the nearest Government station, the reward is claimed, and
he is afterwards cut open, and the contents of his stomach
examined.
Though the animal is spoken to in such flattering terms before he
is secured, the moment his arms and legs are bound across his back
and he is powerless for evil, they howl at him and deride him for his
stupidity.
The professional crocodile catchers are generally Malays, who are
sent for whenever their services are required. But there are Dyaks
who have given up their old superstitious dread of the animal, and
are expert crocodile catchers.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Building An Api Product Design Implement And Release Api Products That Meet User Needs Pedro

More Related Content

Similar to Building An Api Product Design Implement And Release Api Products That Meet User Needs Pedro (20)

Recently uploaded (20)

Building An Api Product Design Implement And Release Api Products That Meet User Needs Pedro