URL-to-File Delivery API: Endpoints, Resumable Transfers and Abuse Protection

Design an API that lets clients download files. A client provides the URL of the file it wants, and the API is responsible for getting that file to the client. Define the endpoints, including their requests, responses and errors, and explain how the service behind the API works. ```hint Not every download fits in one request Think about a file that is very large, a source server that is slow, or a client whose connection drops halfway, and ask whether a single request and response can handle all three. ``` ### Clarifying Questions - Does the URL point to a file our own service already stores, or to any file on the internet that the service must fetch on the client's behalf? - How large can files get, and how many downloads should the API handle at peak? - Who calls the API (browsers, mobile apps or other backend services), and how are they authenticated? - Must interrupted downloads be resumable, and may the service keep a copy of a fetched file to serve later requests for the same URL? ### What a Strong Answer Covers - Scope settled before design, starting with what the URL refers to and who the clients are. - A concrete API: endpoints, methods, request and response bodies, status codes and retry semantics. - Large, slow and interrupted transfers: streaming, resumable byte ranges and asynchronous processing with progress. - Security and abuse protection, including URLs that resolve to internal systems, size limits, malicious content and rate limits. - Scaling, storage and failure handling, with trade-offs explained in terms a product partner can weigh. ### Follow-up Questions - Two clients request the same popular URL a second apart. How do you avoid fetching it twice, and when would reusing a stored copy be wrong? - A mobile user on a weak connection loses the download at 80 percent. What happens next, step by step? - Which metrics would show that the API is healthy and that clients actually receive their files?