User:DKinzler (WMF)/API Guidelines


 * API Guidelines | Product Brief

Resources
For Maintainers


 * Wikimedia_Engineering_Architecture_Principles
 * Core Platform Team/Initiative/Core REST API in Mediawiki/Design principles
 * https://wikitech.wikimedia.org/wiki/Services/FirstDeployment
 * https://wikitech.wikimedia.org/wiki/ServiceOwnership
 * https://wikitech.wikimedia.org/wiki/Deployment_pipeline
 * https://github.com/wikimedia/service-template-node
 * API Life Cycle (draft by Daniel)
 * API versioning
 * https://phabricator.wikimedia.org/T232485 REST Versioning RFC
 * Service-template-node/APIDesign
 * https://api.wikimedia.org/wiki/Community/API_guidelines
 * API_Gateway
 * meta:User:BPirkle (WMF)/Stuff/Designing APIs
 * "Good API, Great API" Google Doc
 * Authorization and Rate Limiting: https://docs.google.com/document/d/1pG2qd4w_RW7wl_6Od1jFo4CkKA3zCA2wQDtmY2e5Tb8/edit#
 * API:Cross-site requests
 * Ideas:
 * paging?
 * localization (mostly for errors)
 * Writing an extension for deployment
 * Wikimedia services policy (see also Requests for comment/Standards for external services)
 * Requests for comment/API roadmap
 * Micosoft API Guidelines, Microsoft API Versioning
 * Google API Guidelines (these seem pretty good!)
 * Maturity model, see also https://blog.restcase.com/4-maturity-levels-of-rest-api-design/
 * List of other people's API Guidelines: https://github.com/masteringapi/rest-api-standards
 * API Description Template
 * API Platform Model
 * Wikimedia API Guidelines
 * Wikimedia Foundation API Principles

For Clients
 * API Life Cycle -> stable interface
 * https://meta.wikimedia.org/wiki/User-Agent_policy
 * API:Etiquette
 * https://api.wikimedia.org/wiki/Documentation/Best_practices
 * https://foundation.wikimedia.org/wiki/Terms_of_Use/en
 * Manual:Creating a bot
 * en:Wikipedia:Bot_policy
 * RESTbase Swagger UI https://en.wikipedia.org/api/rest_v1/
 * Wikidata Data access best practices

Bill's Links


 * https://cloud.google.com/apis/design
 * https://opensource.zalando.com/restful-api-guidelines/index.html#table-of-contents
 * https://meta.stoplight.io/docs/platform/52ab0a117eadd-welcome-to-the-stoplight-docs
 * https://docs.google.com/spreadsheets/d/174pZRPhdL9bMec-87Eho8HB5kV7Ua14fyrxuxoENoh4/edit#gid=1711717114
 * https://docs.google.com/document/d/1h_nvjACYnvqrq93REnubafGckRXqUga3N56bPBPcn9k/edit?pli=1#heading=h.w29abfmznz7v

Search / WDQS


 * https://wikitech.wikimedia.org/wiki/Search/Technical_interactions
 * https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service/Technical_interactions

Bits & Pieces
Note to self: looked at: Adidas, Maturity, Atlassian, Whitehouse, Google, Microsoft, Heroku

Typical Structure & Aspects


 * Documentation
 * discoverable specs and schemas
 * HTTP binding
 * use of verbs, HATEOAS, idempotence (put vs post vs patch)
 * see https://cloud.google.com/apis/design/standard_methods?hl=en
 * see google's idea for custom verbs
 * changing collections https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#95-changing-collections
 * use of error codes, body of error responses
 * content types & negotiation
 * caching
 * conditionals
 * redirects (normalization, deprecation, and other)
 * other headers
 * guidance on urls vs header vs query param
 * resources vs entities
 * etags, see https://cloud.google.com/apis/design/design_patterns?hl=en#etags
 * payload data
 * Wikimedia_Engineering_Architecture_Principles
 * serialization (JSON)
 * shared data model
 * standard data types (date format, language codes, etc)
 * standard field names (rel, ref, etc) - compare https://cloud.google.com/apis/design/standard_fields?hl=en
 * schemas
 * pagination, ordering, filtering
 * https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#98-pagination
 * response for long running operations?
 * standard query params: localization, variants, flavor, embedding/expansion
 * batch operations and collections (put vs post)
 * foreign key relation (entitiy URLs)
 * domains and bounded contexts, separation of concerns
 * no data in keys (really? maps are neat...)
 * errors, compare https://cloud.google.com/apis/design/errors?hl=en
 * Evolution
 * Versioning
 * URL vs headers, etc
 * content negotiation
 * deprecation
 * headers? https://datatracker.ietf.org/doc/html/draft-dalal-deprecation-header-02
 * clients: look for Sunset and Deprecation headers!
 * compatibility, see https://cloud.google.com/apis/design/compatibility?hl=en
 * URL structure
 * characters & encoding (slashes, colons, hashes, utf8, query params, etc)
 * resources & collections (sub-collections, formats, nested resources, etc)
 * nesting vs referense -> composition vs aggregation
 * use American English nouns (singlular or plural?) (kebab-case or CamelCase?)
 * searching vs. listing
 * formats / file extension suffix
 * Compliance
 * testing (pact)
 * SLA, rate limits
 * https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#143-retry-after-and-ratelimit-headers
 * Security
 * Authentication
 * CORS/CSP
 * CSRF
 * Design process (see also https://cloud.google.com/apis/design/resources?hl=en)
 * Model entities (resources, nouns) and their relationships
 * Design a URL scheme for addressing the resources and collections
 * Define schemas for representing the entities.
 * Determine the behavior of standard verbs for each resource (and collection)
 * Clients
 * How to discover APIs
 * Where to find documentation and specs
 * common data types
 * error formats
 * paging
 * Relevant HTTP standards
 * resillience
 * Relevant REST best practices
 * What is stable / unstable
 * use the latest version
 * don't rely on undocumented behavior
 * Follow the ToS
 * Surface Deprecation and Sunsetting
 * Follow 308
 * Be nice
 * Consider the cost
 * Follow 429 / Retry-After
 * Be careful with concurrency
 * React to blocks (403?)
 * Set User-Agent
 * When and how to use auth
 * use OAuth when acting on behalf of others
 * csrf