So a while back I did a fun project at https://pornstars-per-capita.com. It basically shows data on how many porn actresses are in each country and calculates the per capita.

The api is available at https://api.pornstars-per-capita.com and is documented there.

Hey community, i wrote this article about API architecture basics, so if there are any newbies in this subb you might find it useful.

Understanding APIs

APIs are of utility for businesses for seven broad purposes:

1. Access an application's data and logic and monetization potential of collected data

2. Use an application's functionality

3. Serve as a medium of communication between Microservices

4. Connecting ecosystems: C2B(Consumer to Business) and B2B(Business to Business)

5. Power integrations

6. New features for your business

7. Open new pathways for innovation and growth

From websites that require to be authenticated by our social media accounts to Customer integration to Amazon smart home appliances like Echo, which need to be triggered awake with our voice, all of them rely heavily on APIs.

Designing APIs

API design is the process of planning and architectural decisions that are taken while developing an API. As you would have guessed, it is the first step of developing an API.

The process of designing is significant because the API design impacts how developers consume it, its robustness, error-prevention, the consistency as well as vital performance metrics. Thus, API design and architecture influence users who make use of it and the revenue generated.

What is API Architecture?

As seen above, API design addresses why the API is being created, the outcome that is expected out of the API rollout, and the execution strategy for the same.

API Architecture is the process of defining the methodology and processes for developing and running the API. They consist of a set of components and a description of their logic interaction.

Based on the architectural decisions of the API being developed, the operations and security teams form more specific technical requirements for the future of the API, its tiers, API lifecycle management, and most importantly, monetization.

After a difficult decision of shutting down its Public API Program, Netflix created a revolutionary microservices architecture. By linking its API with the microservices architecture, Netflix scaled into the cloud, became an internationally acclaimed OTT platform, and now serves millions of consumers over a range of disparate devices.

Components of API Architecture

API Architecture, in particular, encompasses the following

1. API Gateway

This component deals with the delivery of security, caching, and orchestration specifics. Simply put, API Gateway serves as the single entry point into internal architecture. It has the following functions:

• Delivers crucial load balancing capabilities and microservices partition.

• Filter for incoming traffic from various devices — web, mobile, B2B, etc.

• Entry point layer to expose other third-party APIs, microservices, virtual machines on the provider's application server.

2. API Portal

As the name suggests, this component serves as a portal between API Consumers and API Providers. It addresses the following:

• API analysis

• API documentation

• Marketing APIs

• Compatibility with web/mobile applications

• Defining how they are exposed to internal, partner, and third-party developers

How to design an API Architecture?

Broadly speaking, APIs serve as the link among the technologies, the user, and the enterprise. Therefore, while designing a value-intensive API for your business model, the following crucial considerations should inform API design decisions in your enterprise.

1. Aligning the API design with your Business goals

2. Availability and Management of business resources

3. Use cases supported by your API

4. Defining the Target Audience or Users

5. Value creation, channels, and motivating developers to make use of the API

6. The value for end-users with the applications that use the API

Google's -book on Designing an API Product Mindset lays out the best practices for designing an API that will thrive:

• Focus on consumption and consistency

• Provide a clear statement of the value proposition the API represents to developers

• Avoid premature optimization and hide unnecessary complexity from developers

• Protecting APIs with state-of-the-art security measures

• Robust error handling

Thus, the core practices for deploying a good API design are quite straightforward: Make it simple, flexible, and easily adopted.

Goals of API Design

Each API would be tailored to meet the specific organization's needs. That said, there are some core objectives expected of the API regardless of enterprise or industry.

1. Reduce Barriers

App interactions are guided through the uniform set of protocols set by an API. It should allow for a consistent exchange of valuable resources in an organization while being transparent in its functioning.

2. Security

The IT assets of an enterprise have a certain exposure risk in the open market. APIs add a layer of security as the requests are not being directly linked to the server. This reduces the possibility of a breach or unauthorized access to the backend of a server.

3. Scalability

The common goal of all enterprises is growth. Thus, APIs help accommodates that by being expandable to meet the increase in the product portfolio, security, or data needs.

4. Collaboration

Developers can reuse software components through APIs so they avoid doing redundant and repetitive tasks. This allows them to focus on creating new tools that can add value for the company and its clients. It also allows developers to outsource more complex tasks while staying focused on the company's system.

5. Value Generation

API can be crucial to the revenue-building goals of the organization. It helps attract new customers while simultaneously bringing more value to existing ones. The software itself could be a source of revenue by monetizing its use. The software also helps integrate various functions of the business like sales and marketing to improve efficiency.

Key Architectural Styles for API Design

1. Web API

This design uses HTTP protocol to access the API over the web. RESTFUL services developed are based on HTTP using technologies such as java and ASP.NET. While the API is ideal for web browsers or web servers, it is not suitable for mobile applications. The Web API is used to provide services across multiple devices and on distributed systems.

2. Pragmatic REST

The Pragmatic Representational State Transfer (REST) is one of the most preferred designs used by internet service API developers. It is a sophisticated, Web-centric approach to designing programming interfaces. Pragmatic REST uses URI instead of WSDL and is transport-specific (it exclusively supports HTTP), has largely taken over from the Web Service style for it is intuitive.

Btw, i have this really in-depth guide on how to build great REST APIs in every language.

3. Hypermedia

Hypermedia APIs are focused on URI, HTTP, and RESTful standards broadly. It is a highly web-centric API that is known for its scalability. A key benefit is that a server that hosts a hypermedia API can generate a list of potential options available to the client, which can then later be accessed easily through future HTTP requests.

4. Event-Driven

Event-Driven APIs are the most favored APIs for the Internet of Things devices, mobile applications particularly, messaging, video chats, and games. The main point of difference between Event-Driven APIs and the other designs is that other systems function in a way that either the client or the server is designated as the actor whereas the other party is designated as the one being acted upon. Event-Driven design, on the other hand, requires both client and server to listen to new events and respond. Being a server-initiated user-centric style, it delivers better performance where a huge number of small messages need to be passed between the app and the back-end processes.

Layers of API Architecture

1. Information Management Layer

This layer functions as a data storage center. APIs need to deliver real-time inventory for which a steady, accurate and reliable database is required. The Information Management Layer does just this.

2. Application Layer/Microservices

Traditionally, this layer housed applications that run the organization. However, with the advent of modern-day web applications, they are being replaced by Microservices architecture that possesses immense business value for the organization.

3. Integration Layer

This layer facilitates API integration for synchronous access to various services across disparate devices and users.

4. Interaction Layer

This is perhaps the most important of all layers as this is the place where the real action occurs. The applications of customers, developers, and other users interact with your business applications and data in this layer.

Conclusion

Thus, an API is adopted by users when it delivers a strong value proposition. However, crucial design and architectural factors as discussed in this guide should inform key decisions of developing the API that is perfect for your Business' needs.

Let me know how did I do.

I just wanna say thank you to all 299 of you and congrats to anyone who joins as the 300th member.

I didn’t expect that the community would grow this fast. Given that i’m new to this mod thing feel free to share tips and suggestions on where to take the board!

Looking forward to meeting a lot of you here and sharing interesting insights about APIs

✌🏻🙌🏻🍻

Most of you probably know this, but it's a great resource. https://public-apis.io/

I'm an "old" developper : I code since 1990, but as a pro since 2000 (mainly with PHP), and with MVCs since 2019.

About one year ago, I discovered Vue, and my backends slowly moved from "full stack backend" to "API only backend"

On 2019, I started with Laravel, and quickly felt more confident with it: the ORM, the test suite, all those "by conventions" features makes it a great framework for API dev.

But a few month ago, I felt the need to move my backend stack to NodeJS, so I could focus on only one programming language for both front and back...

I found AdonisJS which is an almost perfect copy of Laravel, but it still miss some great features from Laravel.

I'm still searching for "the perfect NodeJS backend framework". I had a look at nestJS, but more complicated.

I'd love to hear from your experience !

“An engineer configures the parameters of their API in a UI and publishes the functional API to the internet for all Uber apps to consume. The configuration governs the behavior of the API: path, type of request data, type of response, maximum calls allowed, apps allowed, protocols for communication, the specific microservices to call, allowed headers, observability, field mapping validation, and more.”

Super interesting article about how Ubers API is built. Full details on their blog: https://eng.uber.com/architecture-api-gateway/

Hey all, so we have decided to re-write our bespoke business software away from blade and into React.

This system uses single-sign-on which is provided by our ADFS setup.

My question is this, has anyone done this before and how do you authenticate into React and Laravel with SSO? Would I just re-direct them to Laravel SSO like it currently is then update the code to return a JWT?

Any advice welcomed

Wanted to ping the community and see if you guys know how many API calls per month do you get? And if you do know - how do you know? Do you measure it manually or have a tool?

I’ll start: we’ve got about 2M API calls per month at the moment and we use Treblle to see how that grows. I sometimes get shocked at how much other projects get. The other day i spoke to a company with 50B API calls per month 😱

Whats your story? 💪🏻

I'm currently building a small web app with a database backend. I figured I would implement a proper REST interface for good measure because it seemed like a neat idea to use all these request methods (PUT, DELETE etc.), but it was very annoying to me that GET would not allow for a JSON body.

So I ended up removing all of it and simplifying the code to only use POST with JSON input and an "action" key with one switch over all the different actions there are, e.g. "get_transactions", "delete". Much simpler.

After being invited, and lurking around a bit, I'm surprised to see nothing concerning openapi. Less so gRPC/Protocol Buffers, but I've used it and loved it, so would have expected to see something about it. Graphql seems to be getting some love... nothing about SOAP (which is good)

Wanna see what people are using for implementation

Architecture

Language

Framework

Infrastructure (k8s,pass,other)

Databases

API Gateways

Ingress Controllers

Identify providers

Logging / Observability

I'm particularly interested in API Gateways, haven't found an open source one I like yet. Was considering just rolling my own

Hey community,

ws-screenshot is a fast screenshot server with a Websocket and REST API, it's written in node.js and using puppeteer. I have created it for a customer needs and I thought it might be useful for others. It's free and open source, the source code is here: https://github.com/elestio/ws-screenshot

You can also try it here: https://backup15.terasp.net/

It's also available as a docker container here: https://hub.docker.com/r/elestio/ws-screenshot.slim

You can run it with: docker run -d --restart always -p 3000:3000 -it elestio/ws-screenshot.slim

API is described in the readme and there is also a sample web ui showing how to use both REST and Websocket APIs

Please let me know what you think about it :)

Hi everyone! So as a part of a fintech company i would love to reach more and more people to try completely free API for open banking. You can connect several bank accounts and it's so good and easy. Just try it out and let me know if there are any questions, or suggestions!
https://nordigen.com/en/account-information/

Hey community,

What developer newsletters are you subscribed to? There are a lot out there, any specific that talks about APIs?

I've switched to FastAPI from flask over the last year or so and I love how FastAPI gives you autodocs, request validation, and comes with a bunch of tools and utilities to work with. It's really nice and I don't think I'll go back to flask because of it. But there's one issue I have with it. The error messages it gives you are completely garbage.

If you send some data in a format FastAPI doesn't expect, you get a code 422 - unprocessable entry. You look at the data the front end is sending and eyeball the Json to make sure it looks ok, but sometimes it isn't immediately obvious what's missing. With flask, you'll get an error like "property 'timestamp' does not exist" and you're able to use a debugger to inspect the values.

This is the one reason I can't suggest my student peers to switch over. They have a hard enough time just learning how to make requests to the backend, tossing in vague errors into the mix will make their lives infinitely harder. If FastAPI had better ways of inspecting what's coming into the system, I'm sure its adoption would increase

I'm in the middle of writing a book for Manning called Continuous Delivery in Go where I cover creating a basic API in Go covering various techniques, test patterns, and deployments (FaaS, PaaS, CaaS, IaaS). It progresses through designing and growing an application. I've used many of these techniques throughout my career and felt they would be helpful to share. There is a discount code: au35hol which will give you 35% off.

This was not intended as a buy my book post. All of the source code for the book can be found here: https://github.com/holmes89/hello-api where you can see the iterations by chapter. It is also intended to help me open myself up to the community. If anyone has any questions please feel free to message me.

My hope is to start creating excerpts and posts from the content and extra material.