Summary.md

Summary

Design rules have unique and permanent numbers. In the event of design rules being deprecated or restructured, they are removed from the list. Therefore, gaps in the sequence can occur. New design rules will always get a new and higher number.

Normative Design Rules

Design rules can be technical rules, which should be tested automatically and functional rules which should be considerd when designing and building the api.

List of functional rules

• /core/http-safety: Adhere to HTTP safety and idempotency semantics for operations.
• /core/stateless: Do not maintain session state on the server.
• /core/interface-language: Define interfaces in Dutch unless there is an official English glossary available.
• /core/naming-resources: Use nouns to name resources.
• /core/nested-child: Use nested URIs for child resources.
• /core/resource-operations: Model resource operations as a sub-resource or dedicated resource.
• /core/doc-language: Publish documentation in Dutch unless there is existing documentation in English.
• /core/deprecation-schedule: Include a deprecation schedule when publishing API changes.
• /core/transition-period: Schedule a fixed transition period for a new major API version.
• /core/hide-implementation: Hide irrelevant implementation details.
• /core/naming-collections: Use plural nouns to name collection resources.
• /core/changelog: Publish a changelog for API changes between versions.
• /core/geo: Use the GEO module for geospatial content.

List of technical rules

• /core/http-methods: Only apply standard HTTP methods.
• /core/doc-openapi: Use OpenAPI Specification for documentation.
• /core/uri-version: Include the major version number in the URI.
• /core/no-trailing-slash: Leave off trailing slashes from URIs.
• /core/publish-openapi: Publish OAS document at a standard location in JSON-format.
• /core/semver: Adhere to the Semantic Versioning model when releasing API changes.
• /core/version-header: Return the full version number in a response header.