LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Version changes
  • URLs
  • Increment version numbers
  • Deprecating API versions
  • Notify clients when a specific API version will be discontinued

Was this helpful?

  1. Technical overview
  2. API Design Guide

Versioning

PreviousSecurityNextÍsland.is Public Web Data Flow

Last updated 2 years ago

Was this helpful?

Versioning APIs is necessary to ensure the possibility of continuous development of API services. All APIs must provide a major, minor and patch version numbers. The major version number must be included as the first part of the URI path for all APIs.

Version changes

Developers should strive to make all changes backwards compatible (non-breaking changes).

Versioning APIs should follow the specification. Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,

  2. MINOR version when you add functionality in a backwards compatible manner, and

  3. PATCH version when you make backwards compatible bug fixes.

When a major version is incremented, a new instance of the API service must be made available and the older version instance kept running as described in section .

URLs

In all URLs with no exceptions, APIs must expose the major version number, with the character v as a prefix. The minor and patch version numbers should not be exposed in URLs.

Bad

https://my-service.island.is/users
https://my-service.island.is/users?v=1
https://my-service.island.is/users?version=1
https://my-service.island.is/v1.2/users
https://my-service.island.is/v1.2.3/users

Good

https://my-service.island.is/v1/users

Increment version numbers

If an API introduces a breaking change, such as removing or renaming a field, its major version number must be incremented to ensure that existing user code does not suddenly break. Incrementing the major version should be avoided whenever possible to avoid increasing maintenance and cost of running many versions of the same service.

Deprecating API versions

When there are more than one running instances of an API, the old versions need to be decommissioned at some time to reduce maintenance costs.

Notify clients when a specific API version will be discontinued

You should notify clients, who use your service, that the old version will stop working at a specified date. You should give them a link to a new version of the service and provide them with information about all breaking changes between versions. To help with that, you should always provide release notes with every version bump.

The specified date must not be less than 6 months from the time you notify your last client. Exceptions from this rule can be made when you see via your logs that no calls to this API version are made anymore.

For GraphQL APIs use the @deprecated directive on fields which are to be renamed or removed from schemas. Add a descriptive text in the reason: with information on what the client should use in the future. This will allow older clients to continue functioning while updated clients can get the new schema right away. See for more details.

here
semantic versioning
Deprecating API versions