Requirements of the Uber API

Introduction to Uber

Uber is a commonly used application that provides ride-hailing services to users. A user can book a vehicle to travel from a source to a destination. Mainly, two types of users register for the Uber service: a riderThe user that requests a ride requesting a vehicle and a driverThe driver who provides the service providing the ride. Multiple services are used in the Uber system to perform these core functions.

Designing an efficient API for Uber requires an understanding of the services that make up Uber and how they interact with each other. Providing synchronization and status updates with low latency between different users is vital for a service like Uber. For example, the rider requests a ride, and the driver accepts that ride request, but if the rider doesn't get notified in near real-time, then the rider may feel like the application is stuck and might cancel this request and request another ride.

Let's start by identifying the requirements for Uber API.

Requirements

There are multiple functionalities required to design the complete Uber system. We have identified the following functional and non-functional requirements for designing the API for Uber.

Functional requirements

The functionalities are explained in terms of the rider or the driver.

• Book a ride: A rider can request a ride, the estimated time of arrival (ETA), and get an estimate of the fare of the ride using our API. Also, the driver should be able to accept or reject that request while using our services.

• Trip processes: The driver should be able to start and end the ride. Additionally, riders should be able to make modifications, such as adding or removing stops during a trip.

• Rider/driver activities: Riders and drivers should be able to see previous ride histories and current trip details. Additionally, the API should be able to store feedback from drivers and riders. Also, our API should allow users (passengers and drivers) to view and update their profiles.

• Chat: Our API should allow riders and drivers participating in a ride to exchange messages between them.

• Payment: Our API should allow riders to pay fares for rides using different payment methods.

Non-functional requirements

• Availability: The API should allow riders and drivers to use different services at all times. Therefore, the API should be highly available to them.

• Scalability: The API should handle an ever-increasing number of requests.

• Security: The user's payment, profile, ride history, and any other information in the API should be secure.

• Low latency: The API should provide a swift response to the users.

Pre-requisite

Before we start designing the Uber API, we must have a thorough understanding of the following APIs that we’ve designed in different chapters of this course:

• Google Maps API: Uber services employ the Google Maps APIs internally to achieve Uber's functional requirements. For example, the Maps API displays the map to the rider and driver—the route finder API is used to find the optimal path and estimated time of arrival (ETA. Also, the navigation API navigates the driver to the rider's location and then their destination.

• Messenger API: The messenger API enables the rider and driver to chat with each other.

• Payment API: Our Uber API uses the payment API if the rider uses a credit/debit card or the online payment method.

• Rating API: Our Uber API uses rating APIs to get feedback on the driver from the rider and vice versa.

How will we design the Uber API?

This chapter is structured as follows:

• Uber API Design Decisions: This lesson will cover the workflow and technical considerations for Uber API.

• API Model for an Uber Service: This lesson will discuss the API endpoints for each Uber service and the request-response format for them.

• Uber API Design Evaluation and Latency Budget: This lesson will cover how we fulfill the non-functional requirements and estimates the latency budget for our Uber APIs.

Let's start the next lesson with design decisions.