URI: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
Line 11: Line 11:
* [[URL]]
* [[URL]]
* [[URN]]
* [[URN]]
* [[Best Practices for Naming REST API Endpoints#Overview|Best Practices for Naming REST API Endpoints]]
* [[Best Practices for Naming REST API URIs#Overview|Best Practices for Naming REST API URIs]]


=Overview=
=Overview=
Line 17: Line 17:
A Uniform Resource Identifier (URI) is a compact sequence of  characters that identifies an abstract or physical resource. An URI can be a [[URL]] or an [[URN]]. Every URL is a URI, abstractly speaking, but not every URI is a URL.
A Uniform Resource Identifier (URI) is a compact sequence of  characters that identifies an abstract or physical resource. An URI can be a [[URL]] or an [[URN]]. Every URL is a URI, abstractly speaking, but not every URI is a URL.


REST APIs use URIs to address resources. [[Best Practices for Naming REST API Endpoints#Overview|Best Practices for Naming REST API Endpoints]] contains some rules to use when creating URIs for resources.
REST APIs use URIs to address resources. [[Best Practices for Naming REST API URIs#Overview|Best Practices for Naming REST API URIs]] contains some rules to use when creating URIs for resources.


Tim Berners-Lee: "The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain information". This seems to advocate for URI opacity. However, REST API designers should create URIs that convey a REST API's resource model to its clients.
Tim Berners-Lee: "The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain information". This seems to advocate for URI opacity. However, REST API designers should create URIs that convey a REST API's resource model to its clients.
Line 32: Line 32:


==Authority==
==Authority==
Also see: {{Internal|Best_Practices_for_Naming_REST_API_Endpoints#Authority_Rules|Best Practices for Naming REST API Endpoints | Authority Rules}}
Also see: {{Internal|Best_Practices_for_Naming_REST_API_URIs#Authority_Rules|Best Practices for Naming REST API URIs | Authority Rules}}


==Path==
==Path==


==Query==
==Query==
Also see: {{Internal|Best_Practices_for_Naming_REST_API_Endpoints#URI_Query_Rules|REST API Query Rules}}
Also see: {{Internal|Best_Practices_for_Naming_REST_API_URIs#URI_Query_Rules|REST API Query Rules}}


==Fragment==
==Fragment==

Revision as of 23:33, 14 February 2024

External

Internal

Overview

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. An URI can be a URL or an URN. Every URL is a URI, abstractly speaking, but not every URI is a URL.

REST APIs use URIs to address resources. Best Practices for Naming REST API URIs contains some rules to use when creating URIs for resources.

Tim Berners-Lee: "The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain information". This seems to advocate for URI opacity. However, REST API designers should create URIs that convey a REST API's resource model to its clients.

Format

RFC 3986 defines the generic URI syntax:

scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]

Scheme

Authority

Also see:

Best Practices for Naming REST API URIs | Authority Rules

Path

Query

Also see:

REST API Query Rules

Fragment

URI Template

https://datatracker.ietf.org/doc/html/draft-gregorio-uritemplate