[ByteByteGo Daily] API redesign: shopping cart and Stripe payment

[reboottime]

Overview

This article illustrated a step by step guide on API design and the evolution of stripe payment API designs.

The original source is from an Alex Xu's newsletter article API redesign: shopping cart and Stripe payment

Step 1: Setup Requirements assumption

1. Creating a cart

2. Viewing a cart

3. Adding an item to a cart

4. Viewing items within a cart

The basic API design is as following

One noticeable thing is we use mine as the special cart identifier because a user has only one shopping cart.

Wen we add an item to a cart, a Google Style API might specify the verb in the URL like so

POST /v1/carts/mine/items:add

[reboottime]

Step 2: Optimization

• Filtering
• Sortting
• Pagination
  • However, offset pagination does not work well for large datasets.
  • offset pagination also doesn't work well for datasets that are being written too frequently, a good example is messagint in a busy chat group: High data velocity can lead to duplicates or skipped results.
  • On the other hand, cursor-based pagination uses a pointer to a specific item. It returns results after that pointer in subsequent requests. This method is based on a unique, sequential column in the table, and it offers advantages in scalability and stability over offset pagination. It doesn't require rescanning the dataset up to the offset for each request. An example for cursor based pagination could look like this

GET /v1/carts?maxPageSize={maxPageSize}&pageToken={pageToken}

{
    results: [...],   
    nextPageToken={ xxx }
}

• Pros: The cursor points to a specific row on a primary column, and the database can use the index to jump to that specific location quickly, without resorting to a table scan.
• Cons: However, cursor-based pagination sacrifices the ability to jump to a specific page.

[reboottime]

Step 3: Security

Many shopping carts allow item adding without signing in. This is known as anonymous cart functionality. These public APIs become potential DDoS attack targets. We must guard against attackers adding or removing a large number of items from tens of thousands of PCs, leading to system resource exhaustion.

When designing APIs, it’s crucial to employ appropriate rate-limiting algorithms for DDoS attack prevention. This can be implemented at the firewall or API gateway level. For example, firewalls can reject recurrent requests from a single IP address, while API gateway could limit “add to or remove from shopping cart” requests to 100 per minute.

[reboottime]

Example 3: Stripe API redesign

The evolution of Stripe API design