دانلود کتاب طراحی API برای مهندسان سیستم: مبانی، طراحی عملی، امنیت، تکامل و عملیات

The central idea is that an API is a long-lived agreement about observable behavior. URLs and payloads matter, but they are only parts of that agreement. A useful design also defines meanings, permissions, failures, timing expectations, compatibility rules, and ownership. After completing this chapter, you will be able to: • Explain why an API is a contract for observable behavior rather than merely a set of URLs. • Distinguish API design, implementation, and operation responsibilities. • Identify coupling, quality attributes, lifecycle stages, and ownership concerns that shape a durable boundary. An application programming interface (API) is a defined way for one software component to request capabilities or exchange data with another. The component that offers the API is the provider. A component that calls it is a client or caller. The word consumer is broader: it may refer to a client application, another service, a team, or an organization that depends on the API. A downstream dependency is a system that the provider itself must call or rely on to complete some requests. Suppose a support-ticket provider offers an operation for retrieving a ticket. The contract may promise that: • A ticket has a stable identifier. • A successful retrieval returns a specific data structure. • A missing ticket produces a defined error. • A caller must have permission to view the ticket. • Existing fields will not silently change meaning.