Cargando…

API design patterns /

API Design Patterns lays out a set of design principles for building internal and public-facing APIs. Google API expert JJ Geewax presents patterns that ensure your APIs are consistent, scalable, and flexible. You'll improve the design of the most common APIs, plus discover techniques for trick...

Descripción completa

Detalles Bibliográficos
Clasificación:Libro Electrónico
Autor principal: Geewax, J. J. (John J.) (Autor)
Otros Autores: Skeet, Jon (writer of foreword.)
Formato: Electrónico eBook
Idioma:Inglés
Publicado: New York : Manning Publications Co. LLC, [2021]
Temas:
Acceso en línea:Texto completo (Requiere registro previo con correo institucional)
Tabla de Contenidos:
  • Intro
  • inside front cover
  • API Design Patterns
  • Copyright
  • dedication
  • contents
  • front matter
  • foreword
  • preface
  • acknowledgments
  • about this book
  • Who should read this book
  • How this book is organized: A roadmap
  • About the code
  • Live book discussion forum
  • Other online resources
  • about the author
  • about the cover illustration
  • Part 1 Introduction
  • 1 Introduction to APIs
  • 1.1 What are web APIs?
  • 1.2 Why do APIs matter?
  • 1.3 What are resource-oriented APIs?
  • 1.4 What makes an API "good"?
  • 1.4.1 Operational
  • 1.4.2 Expressive
  • 1.4.3 Simple
  • 1.4.4 Predictable
  • Summary
  • 2 Introduction to API design patterns
  • 2.1 What are API design patterns?
  • 2.2 Why are API design patterns important?
  • 2.3 Anatomy of an API design pattern
  • 2.3.1 Name and synopsis
  • 2.3.2 Motivation
  • 2.3.3 Overview
  • 2.3.4 Implementation
  • 2.3.5 Trade-offs
  • 2.4 Case study: Twapi, a Twitter-like API
  • 2.4.1 Overview
  • 2.4.2 Listing messages
  • 2.4.3 Exporting data
  • Summary
  • Part 2 Design principles
  • 3 Naming
  • 3.1 Why do names matter?
  • 3.2 What makes a name "good"?
  • 3.2.1 Expressive
  • 3.2.2 Simple
  • 3.2.3 Predictable
  • 3.3 Language, grammar, and syntax
  • 3.3.1 Language
  • 3.3.2 Grammar
  • 3.3.3 Syntax
  • 3.4 Context
  • 3.5 Data types and units
  • 3.6 Case study: What happens when you choose bad names?
  • 3.7 Exercises
  • Summary
  • 4 Resource scope and hierarchy
  • 4.1 What is resource layout?
  • 4.1.1 Types of relationships
  • 4.1.2 Entity relationship diagrams
  • 4.2 Choosing the right relationship
  • 4.2.1 Do you need a relationship at all?
  • 4.2.2 References or in-line data
  • 4.2.3 Hierarchy
  • 4.3 Anti-patterns
  • 4.3.1 Resources for everything
  • 4.3.2 Deep hierarchies
  • 4.3.3 In-line everything
  • 4.4 Exercises
  • Summary
  • 5 Data types and defaults
  • 5.1 Introduction to data types
  • 5.1.1 Missing vs. null
  • 5.2 Booleans
  • 5.3 Numbers
  • 5.3.1 Bounds
  • 5.3.2 Default values
  • 5.3.3 Serialization
  • 5.4 Strings
  • 5.4.1 Bounds
  • 5.4.2 Default values
  • 5.4.3 Serialization
  • 5.5 Enumerations
  • 5.6 Lists
  • 5.6.1 Atomicity
  • 5.6.2 Bounds
  • 5.6.3 Default values
  • 5.7 Maps
  • 5.7.1 Bounds
  • 5.7.2 Default values
  • 5.8 Exercises
  • Summary
  • Part 3 Fundamentals
  • 6 Resource identification
  • 6.1 What is an identifier?
  • 6.2 What makes a good identifier?
  • 6.2.1 Easy to use
  • 6.2.2 Unique
  • 6.2.3 Permanent
  • 6.2.4 Fast and easy to generate
  • 6.2.5 Unpredictable
  • 6.2.6 Readable, shareable, and verifiable
  • 6.2.7 Informationally dense
  • 6.3 What does a good identifier look like?
  • 6.3.1 Data type
  • 6.3.2 Character set
  • 6.3.3 Identifier format
  • 6.3.4 Checksums
  • 6.3.5 Resource type
  • 6.3.6 Hierarchy and uniqueness scope
  • 6.4 Implementation
  • 6.4.1 Size
  • 6.4.2 Generation
  • 6.4.3 Tomb-stoning
  • 6.4.4 Checksum
  • 6.4.5 Database storage
  • 6.5 What about UUIDs?
  • 6.6 Exercises
  • Summary
  • 7 Standard methods
  • 7.1 Motivation
  • 7.2 Overview