API design types
HOW API CALLS ARE CREATED
Service oriented web API:s
Web-based API:s are usually REST (Representational State Transfer) API:s utilizing HTTPS-protocol.
REST has replaced XML-based SOAP (Simple Object Access Protocol) as a messaging method.
Currently message based integrations are common.
Many services nowadays provide a REST API to their customers.
Banks
Tax office
Insurance companies
https://www.mobilelive.ca/blog/why-backend-for-frontend-application-
architecture
REST-API
Normal REST-API provides functions to complete use cases like:
addProductToOrder
deleteAddressFromAddressBook
acceptDeliveryTerms
There is normally one function for each use case
Functions are used to access resources using HTTP methods:
addProductToOrder PUT /api/v1/order/:productid
Update ORDER resource by adding a product reference (called shop cart item) for it.
Product to be added is identified by productid
Examples
Shows how REST APIs are used for two different use cases:
Book a hotel room
Add a new booking to database
There is a room referencing the booking
User will be clarified from authentication, booking will refer user
and room
POST /hotel/api/v1/booking/:roomid
Cancel a train ticket (=Set the status of train ticket to
cancelled)
Update the status of existing train ticket (do not delete it!)
PUT /trainsystem/api/v1/tickets/:ticketid/cancel
UPDATE TICKETS SET STATUS = ’cancel’ where ticketid=$TICKETID
(pseudo code)
Types of API:s
BASED ON THE TARGET GROUP
Types of API:s (who is able to access)
Open APIs are entirely free and entirely open to the public. They require no
authentication to access or retrieve data.
Often (but not always) provide only data retrieval functions to users. Clients are
not able to add data to database.
Public APIs
API documentation and endpoint are available in Internet
Need registration and authentication
May have service levels and monitoring/restrictions of number of transactions
issued
May have price
Types of API:s (who is able to access)
Partner APIs
Are more limited in who can access the service. They can be either free or paid.
Since partner APIs are only made available to certain parties, they tend to have
tighter and stricter rules around authorization, authentication, and security.
Private API:s
Intended for certain client application or client company for internal use.
E.g. Backends for frontends:
When certain mobile app needs a backend server to execute application
specific database transactions, a dedicated backend service with private API is
created. (No other applications are exptected to connect)
Composite APIs
Sometimes one use case can consist of several related API-calls.
If API provides composite API endpoint, client can create one composite API-call,
where it collects all related API-calls to be executed by the server one after
another.
Can make apps more efficient as it keeps the number of API calls to a bare
minimum
Composite example: With a single call to addItemToOrder application can:
Create a new User ID (call internally API function createNewUser, if it does not exist)
Create a new Order Number (call internally API function createNewOrder, if it does not
exist)
Add an item to the order
Decrease the inventory count for that product
Change order status [8]
Composite APIs
By providing use case based services, you can try to avoid performance issues
related to individual API calls (network requests) and thus avoid need to create
composite API.
API client should not call removeItemFromInventory through the API, but shop server
should do it internally. Same applies to change order status.
Batch APIs
Batch API:s work like composite API:s, but there you can combine several, not
related, same type of service calls into one request.
E.g. In order to create 20 new products (call createProduct 20 times over network), you
can combine them all into same request.
Unified APIs [8]
Unified API:s [8]
Unified APIs are similar to composite APIs, except they bundle together multiple APIs and
backend resources into one. They’re aggregators, frequently bundling together common
functionality or APIs from a specific sector like banking or CRM solutions.
Obviously, unified APIs raise some logistical concerns and security risks. Unified API
providers need to keep these considerations in mind, offering additional abstraction layers
and field-level encryption, for instance.
Data field can be delivered to many API:s, but it can be opened by only one of those (the one
having secret key, that is able to decrypt the message
Many financial SaaS platforms are actually unified APIs. Think of Stripe Payment, which can
accept payment from virtually any payment provider.
References
1. Phan, K.A., 2008. Similarity-Based SOAP Multicast Protocol to Reduce Bandwith and Latency in Web Services. IEEE
transactions on services computing 1, 88–103.
2. IBM, Redbooks. WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook, I B M,
2004. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/tritonia-ebooks/detail.action?docID=3306761.
Created from tritonia-ebooks on 2021-11-09 14:34:31.
3. EJB 3 In Action. 2nd edition. https://livebook.manning.com/book/ejb-3-in-action-second-edition/chapter-1/point-
13381-64-64-0
4. https://www.guru99.com/comparison-between-web-services.html
5. https://www4.cs.fau.de/~geier/corba-faq/corba-and-ejb.html
6. https://whatis.techtarget.com/definition/IIOP-Internet-Inter-ORB-Protocol
7. Fielding, Roy, 2000, Architectural Styles and the Design of Network-based Software Architectures DISSERTATION
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1
8. “6 Types of APIs: Open, Public, Partner, Private, Composite, Unified | Nordic APIs |.” https://nordicapis.com/6-
types-of-apis-open-public-partner-private-composite-unified/ (accessed Aug. 01, 2022).
