Requirements of the Twitter API

Introduction to the Twitter API

Twitter is a social media platform where millions of users share their TweetsA Tweet can contain text, images, or videos.The tweet can consist of text, images, or videos. and billions of other users react to those Tweets on a daily basis. Twitter provides users with an interface where they can perform different operations. However, behind the scenes, many services and components interact to create a Tweet, generate a timelineThe timeline includes a stream of Tweets and various recommendations based on the user's interests and followers' activity (such as their Tweets, Retweets, likes, etc.)., and perform other relevant tasks.

Designing an API for a platform like Twitter requires an in-depth understanding of the back-end system. In this chapter, we provide an overview of the workflow of the Twitter system and then move on to designing an API for it.

Let's establish the expectations from our API by defining some requirements.

Requirements

This section discusses the functional and non-functional requirements that the Twitter API needs to fulfill.

Functional requirements

• Post a Tweet: The API should allow users to post a Tweet. Apart from text, users should be able to upload images, videos, or any (non-executable) documents to the platform as part of the Tweet.

• View timeline: It should be possible for users to retrieve their timelines.

• Search: The API should enable users to search for any Tweet or account.

• Comment on a Tweet: The users should be able to comment on a Tweet.

• Rate a Tweet: The users should be able to like a Tweet (or unlike a liked Tweet).

Note: Most of these core functionalities require the users to be authenticated. However, some of the functionalities mentioned above are already available to us in the form of building blocks that we designed earlier.

Non-functional requirements

• Availability: The service should be highly available to the end users.

• Reliability: The system should act reliably, even if some services fail. For example, the users should be able to view Tweets even if they cannot post them temporarily.

• Scalability: The service should be scalable to handle the ever-increasing number of users and their requests.

• Security: The service should be able to securely store and communicate user data by employing appropriate security mechanisms.

• Low latency: The response time of the services should be near to real-time in order to provide users with a smooth experience.

Prerequisites

Because some of Twitter's functionality has already been discussed elsewhere in this course, we will provide the pointers to them, instead of repeating them here.

• Search API: This API allows users to find Tweets or other entities based on their search query.

• Comment API: Twitter's comment functionality requires the comment API to allow users to perform CRUD operations on a Tweet's comment.

• Rating API: The rating functionality requires the rating API to allow users to rate Tweets.

• Pub-sub API: The Tweet service requires the pub-sub API to notify the timeline service about a newly posted Tweet.

• File upload API: The Tweet service requires the file upload API because it allows users to upload any media file.

How will we design the Twitter API?

This chapter is composed of the following lessons.

1. Twitter API Design Decisions: In this lesson, we will discuss the workflow and design considerations for Twitter's APIs.

2. API Model for Twitter Service: This lesson focuses on the endpoints and message format for Twitter's APIs.

3. Twitter API Design Evaluation and Latency Budget: This lesson covers the non-functional requirements and optimization for common scenarios related to Twitter's APIs. We will also learn to estimate the response time for the Twitter API in this lesson.

Let's start with the discussion of design decisions to pave our way toward the development of Twitter's API.