National Addressing System

Ministry of Housing and Urban Planning in the Sultanate of Oman

User Tools

Site Tools


reference:system-architecture:address-editing-and-query-api

This is an old revision of the document!


NAS Address Editing and Query API Specification

1. RESTful API

Types of actions in a REST API

  • HttpGet: This method is used to retrieve and query records from the database.
  • HttpPut: This function updates existing records.
  • HttpPost: Utilised for creating new entries in the database.
  • HttpDelete: This method deletes records currently stored.

For each data type, a unique controller oversees these actions, ensuring a structured and coherent data handling process. The API is designed to be user-friendly, adhere to industry standards, and is thoroughly documented.

2. Technical approach

From the outset, the technical approach involves utilising:

  • Fast API: Known for its speed and efficiency.
  • Python >= 3.12: The latest iteration of the Python programming language.
  • Containerization using Docker: The leading technology for containerization of server applications

Linux operating system: A robust and proven platform for hosting services.

This structure aims to enhance the National Addressing System's functionality, supporting accurate and efficient data management and integration across various platforms.

2.1 Performance Management, Rate Limiting, Caching, and Developer Enablement

To ensure reliable, scalable, and fair access to the NAS API ecosystem—particularly as integrations expand to include both public and private third-party systems—the platform should adopt additional operational controls and developer support mechanisms:

2.2 Rate Limiting and Caching

The NAS API layer will benefit from the implementation of rate limiting to prevent abuse, ensure equitable resource allocation, and protect backend systems from overload during periods of high demand. Rate limiting policies will be clearly defined in API documentation and enforced per API client or token, with the flexibility to grant higher limits to critical government and infrastructure partners.

Complementing rate limiting, API-level caching mechanisms (e.g., in-memory caches, reverse proxies, or CDN-based edge caching) will be deployed to accelerate the most frequently accessed data and reduce repeated queries to the primary database. Caching strategies will be tailored according to data volatility and use-case, balancing data freshness against system responsiveness.

2.3 Service Level Agreements (SLAs) for Integrations

For all external integrations, especially those with business-critical third-party systems, formal Service Level Agreements (SLAs) will be established. SLAs will define key parameters such as guaranteed uptime, target response times, maintenance notification windows, and escalation procedures for incidents. This transparency fosters trust among stakeholders and ensure predictable quality of service for mission-critical operations.

2.4 Performance Benchmarks and Scalability Thresholds

To guide system sizing and support future growth, the NAS API and underlying infrastructure will be subject to regular performance benchmarking. Metrics such as average and 95th percentile response times, throughput under load, and maximum supported concurrent connections will be documented. Scalability thresholds (e.g., API requests per minute, data volume limits, user concurrency) will be specified and reviewed as usage patterns evolve.

2.5 Sandbox Environments for Integration Testing

To facilitate secure and efficient onboarding of new integrators, a sandbox environment—mirroring the production API but operating on test data—will be provided to registered developers. This environment enables third parties to prototype and validate their integrations without risk to production data or services. Comprehensive API documentation, test credentials, and sample data will be made available within the sandbox to accelerate development and troubleshooting.

3 API methods specification

The API must as minimum implement the following methods. Authentication is exempt but implicitly required for acceptable system operations.

_PARATABLE_INS_Tag^_PARATABLE_INS_Method_PARATABLE_INS_Endpoint^_PARATABLE_INS_Description
_PARATABLE_INS_address-unit |_PARATABLE_INS_GET_PARATABLE_INS_/address-unit/read-all|_PARATABLE_INS_Read all address units
_PARATABLE_INS_GET|_PARATABLE_INS_/address-unit/read/{adrutid}_PARATABLE_INS_Read one address unit| | | |_PARATABLE_INS_POST_PARATABLE_INS_/address-unit/upsert|_PARATABLE_INS_Insert or update an address unit
_PARATABLE_INS_DELETE|_PARATABLE_INS_/address-unit/delete/{adrutid}_PARATABLE_INS_Delete an address unit| | | |POST|/address-unit/sync|Synchronise uploaded dataset with server| | | | | | | | |_PARATABLE_INS_sub-address _PARATABLE_INS_GET|_PARATABLE_INS_/sub-address/read-all_PARATABLE_INS_Read all sub-addresses| | | |_PARATABLE_INS_GET_PARATABLE_INS_/sub-address/read/{adrutid}|_PARATABLE_INS_Read one sub-address
_PARATABLE_INS_POST|_PARATABLE_INS_/sub-address/upsert_PARATABLE_INS_Insert or update a sub-address| | | |_PARATABLE_INS_DELETE_PARATABLE_INS_/sub-address/delete/{adrutid}|_PARATABLE_INS_Delete a sub-address
POST/sub-address/syncSynchronise uploaded dataset with server
_PARATABLE_INS_street |_PARATABLE_INS_GET_PARATABLE_INS_/street/read-all|_PARATABLE_INS_Read all streets
_PARATABLE_INS_GET|_PARATABLE_INS_/street/read/{adrutid}_PARATABLE_INS_Read one street| | | |_PARATABLE_INS_POST_PARATABLE_INS_/street/upsert|_PARATABLE_INS_Insert or update a street
_PARATABLE_INS_DELETE|_PARATABLE_INS_/street/delete/{adrutid}_PARATABLE_INS_Delete a street| | | |POST|/street/sync|Synchronise uploaded dataset with server| | | | | | | | |_PARATABLE_INS_street-segment _PARATABLE_INS_GET|_PARATABLE_INS_/street-segment/read-all_PARATABLE_INS_Read all street segments| | | |_PARATABLE_INS_GET_PARATABLE_INS_/street-segment/read/{adrutid}|_PARATABLE_INS_Read one street segment
_PARATABLE_INS_POST|_PARATABLE_INS_/street-segment/upsert_PARATABLE_INS_Insert or update a street segment| | | |_PARATABLE_INS_DELETE_PARATABLE_INS_/street-segment/delete/{adrutid}|_PARATABLE_INS_Delete a street segment
POST/street-segment/syncSynchronise uploaded dataset with server
_PARATABLE_INS_issues |_PARATABLE_INS_GET_PARATABLE_INS_/issues/read-all|_PARATABLE_INS_Read all issues
_PARATABLE_INS_GET|_PARATABLE_INS_/issues/read/{adrutid}_PARATABLE_INS_Read one issue| | | |_PARATABLE_INS_POST_PARATABLE_INS_/issues/upsert|_PARATABLE_INS_Insert or update an issue
_PARATABLE_INS_DELETE|_PARATABLE_INS_/issues/delete/{adrutid}_PARATABLE_INS_Delete an issue| | | |POST|/issues/sync|Synchronise uploaded dataset with server| | | | | | | | |_PARATABLE_INS_start-stop _PARATABLE_INS_GET|_PARATABLE_INS_/start-stop/read-all_PARATABLE_INS_Read all start-stop points| | | |_PARATABLE_INS_GET_PARATABLE_INS_/start-stop/read/{adrutid}|_PARATABLE_INS_Read one start-stop point
_PARATABLE_INS_POST|_PARATABLE_INS_/start-stop/upsert_PARATABLE_INS_Insert or update a start-stop point| | | |_PARATABLE_INS_DELETE_PARATABLE_INS_/start-stop/delete/{adrutid}|_PARATABLE_INS_Delete a start-stop point
POST/start-stop/syncSynchronise uploaded dataset with server
query
GET/query/free-text
GET/query/streets
GET/query/wilayat
GET/query/governorate
download GET/download/all
GET/download/changes/{since}

A reference implementation of the API has been prepared and may be used directly or built on when implementing the final system

reference/system-architecture/address-editing-and-query-api.1756243399.txt.gz · Last modified: by runarbe