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
  • General
  • Resources
  • URIs
  • Fields
  • References

Was this helpful?

  1. Technical overview
  2. API Design Guide

Naming Conventions

PreviousMethodsNextOnce Only Principle

Last updated 2 years ago

Was this helpful?

This document describes API naming conventions related to services and resources, with focus on the general consumer experience. Consistency and clear naming conventions are key to providing uniform APIs between agencies. For further information about our naming conventions for the developer experience please refer to our .

General

In order to provide a consistent consumer experience across the API ecosystem and over a long period of time, all names used by an API should be:

  • simple

  • intuitive

  • consistent

One goal of these naming conventions is to ensure that the majority of consumers can easily understand an API. It does this by encouraging the use of a simple, consistent and small vocabulary when naming methods and resources. It also enforces names to be in British English. Developers should use our when in trouble finding the appropriate English translation of an Icelandic concept.

Commonly accepted short forms or abbreviations of long words may be used for brevity. For example, API is preferred over Application Programming Interface. Use intuitive, familiar terminology where possible. For example, when describing removing (and destroying) a resource, delete is preferred over erase. Use the same name or term for the same concept, including for concepts shared across the ecosystem.

Name overloading should be avoided. Use different names for different concepts. Overly general names that are ambiguous within the context of the API and the larger API ecosystem should be avoided as they can lead to a misunderstanding of API concepts. Specific names that accurately describe the API concept and distinguish it from other relevant concepts should be used. There is no definitive list of names to avoid, as every name must be evaluated in their context.

Bad

Info        // info about what?
Service     // service for what?
Application // application for what?

Good

OrderStatus    // Info about Order status
OrderService   // Service that works with the Order resource
PaternityLeave // Application data for paternity leave application

Carefully consider using names that may conflict with keywords in common programming languages. Such names may be used but will likely trigger additional scrutiny during API review. Use them judiciously and sparingly.

Resources

Resource names should be singular noun and use PascalCase.

Bad

Users
user
Paternityleave

Good

User
PaternityLeave

URIs

https://example.com:8042/over/there?name=ferret#nose
\___/   \______________/\_________/ \_________/ \__/
  |            |            |            |        |
scheme     authority       path        query   fragment

When structuring resource URIs please follow the following rules:

  • [Resource names and collection IDs] must be the plural form of the singular noun used for the resource.

  • Use lowercase letters for URI paths since capital letters can sometimes cause problems.

  • Use hyphens (-) to improve readability of concatenated resource names.

  • Use the forward slash (/) in a path to indicate hierarchical relationship between resources.

  • Do not end a path with a trailing forward slash (/).

  • Do not use underscores (_) as they can be partially obscured or hidden in some browsers or screens.

  • For naming query parameters please use the camelCase naming convention.

Example URI of an authority and a path component

example.com/v1/users/1/photos/121
\_________/ |  \___/   \____/ \_/
    |       |    |        |    \
    |       |    |        |      Resource ID
    |       |    |        |         (type)
    |       |    |         \
    |       |    |           Collection ID
    |       |    |              (type)
    |       |     \
    |       |      Resource name of parent resource
    |        \
    |          Major version
      \
        API service name

Fields

Resource field names should be clear, descriptive and use camelCase. Fields representing arrays or lists should be named as plural nouns.

Bad

User:
  type: object
  properties:
    Name:
      type: string
    DisplayName:
      type: string
    dspName:
      type: string
    Email:
      type: string
    child:
      type: array

Good

User:
  type: object
  properties:
    name:
      type: string
    displayName:
      type: string
    email:
      type: string
    childs:
      type: array

References

The defined in consists of five components: scheme, authority, path, query and fragment.

coding standard
glossary
URI
RFC3986
Google
restfulapi.net