What are Path Parameters in a URI?

Asked

Viewed 10,675 times

29

  • What are the path Parameters of a URI and its function?
  • A URI that defines the parameters represents a resource other than the URI that does not have the parameters? This is, /foo;v=1.0 is a different resource from /foo?

If possible, give examples of your application/function.

Because until then, the URI format I knew was:

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

But today I ended up realizing the existence of another item:

  foo://example.com:8042/over/there;param=value;p2;p3?name=ferret#nose
  \_/   \______________/\_________/ \_______________/ \_________/ \__/
   |           |            |              |              |         |
scheme     authority       path          params         query   fragment

Where the RFC3986 recommends using the character ; to separate the parameters, the character = to separate the value name, and the character , to separate multiple values of the same parameter.

uri

  • I saw some mention of that path and parameters in the last paragraph of the section you linked (3.3 Path). He claims that with the exception of dot-Segments, the path URI is opaque. And use ; and = would be a common practice, not necessarily recommended; it also says that , may have the same semantics as ;, depending on the use only of who is implementing

  • @Jeffersonquesado Yes, but what does it really mean? What would be opaque in this context? That the user defines the path without knowing exactly how it will be handled by the application? And in the case of the parameters, what would be their real function? I’ve never seen this in practice and it’s hard to find any quote beyond the specification itself about it.

  • Opaque: path is opaque for URI recognition, so the URI does not see its inner parts. What does the params, I’m still researching here not to give an unfounded answer, but it seems that is vendor specific. I’m also after the information, but it’s a pretty big deal. I don’t think any library that reads URI cares too much about this explicitly, just the application that’s going to try to make sense of it

  • 1

    Exactly. From what I understood it could be used, for example, to specify the version of an API through the URI itself: GET /api/users;v=1.0 HTTP/1.1, or something like that. It seems that it is something that has been specified without a very clear purpose and each one uses as it wishes - which is kind of strange, because the URL could become inconsistent between different applications.

  • I’ll answer your question, I think if you’re going to approach everything would be too big, I’ll try to summarize, if you find that more details are still missing, add a comment that I add.

3 answers

14

There’s a subtle difference between Path params and params Query that I take the liberty of translating to Parâmetros do caminho da Url and Parâmetros de Consulta

Both do the same thing but in different ways.

Parameters of the URL

  • Leaves the friendly url (SEO, user, etc)
  • In theory, it’s something important in the url, something of value

  • If the parameter passed is invalid it can occur 404

    ex: GET parentes/avo/detalhes

Query Parameters (Or Querystring)

  • Less SEO friendly urls (difficult user understanding)

  • In theory it is something superfluous for url execution, such as filters, sorts, etc.

  • Does not cause 404 if parameter is invalid
  • ex: GET parentes/detalhes?tipo=avo

The default for querystring parameters is:

| Tipo    | Descrição                                         |
|---------|---------------------------------------------------|
| ?       | antes do primeiro valor                           |
| {param} | Nome do parâmetro                                 |
| =       | separação do parâmetro e valor com sinal de igual |
| {value} | valor do parâmetro                                |
| &       | para separar demais parâmetros                    |

ex: url/pagina?parametro1=valor&parametro2=valor

For SEO the first way is the recommanded, since the parameter is something useful in the page, if it is only a filter, you can use the second way.

Who will differentiate what is a path from the url or what is a simple parameter is you in developed, based on common sense.

The article itself says:

3.4 . Query

The query component contains non-hierarchical data which, along with path data ( Section 3.3 ), serves to identify a resource within the scope of the URI scheme and authority (if any). The consultation component is indicated by the first character ("?") and ended by a sign ("#") or until the end of the URI.

3.3 . Path

The path component contains data, usually organized in a hierarchical, which together with data in the query component hierarchical ( Section 3.4 ), serves to identify a resource within the scope of the URI scheme and appointing authority (if any). The path is closed by the first question mark ("?") ...

Based on this understanding, we can answer the questions:

path Parameters of a URI and what its function is?

The function is to pass parameters hierarchically to a page, these parameters are unpredictable for the operation of this page, different from the query that are not mandatory.

UPDATE: After analyzing the comma point function and mainly the @Leonancarvalho response;

For example, semicolon (";") and matching reserved characters ("=") are often used to delimit parameters and values of parameters applicable to this tracking. The reserved character of the comma (",") is often used for similar purposes. By example, a Producer URI can use a segment as "name; v = 1.1" to indicate a reference to version 1.1 of the "name" while another can use a segment as "name, 1.1" to specify the same.

I see that the semicolon has the same effect as the equals sign, they serve to separate values. Remembering that some systems can interpret the ; as SQL Injection Code, causing problems or 500.1 errors on the site.

More information on:

https://softwareengineering.stackexchange.com/questions/270898/designing-a-rest-api-by-uri-vs-query-string

https://stackoverflow.com/questions/30967822/when-do-i-use-path-params-vs-query-params-in-a-restful-api

https://tools.ietf.org/html/rfc3986#Section-3.4

  • 1

    "Sign number # character"? I think the translator played a trick

  • Very good softwareengineering link

  • It was not clear what part of the parameters of path, because it seems you’ve only considered the path yes. If I specify a URL like /foo/baz;version=1.0, the path will be the /foo/baz and the parameters of path will be version=1.0 (understand that it is not the query). I did not see in your reply any reference to this second.

  • query is only added after ? everything before is url parameter

  • @Dorathoto then you claim that at URI /foo;bar=1, so much foo as bar=1 are semantically the same thing? Why do the two syntaxes exist then?

  • In short, I still can’t understand how this answers the question. I asked about the path Parameters and you commented on path and query. Comment on the path I think it’s valid, but I don’t see any relation to path Parameters with the query.

  • I will try to improve the answer @Andersoncarloswoss really do the same thing, so I wanted to make a comparison what the differences, and if there is one better than the other? does not depend on the project

  • @Dorathoto as to the last question: I do not understand why you say that /foo;v=1.0 would be invalid, RFC 3986 itself predicts this syntax; and the question is as to which resource is represented by each URI. For example, if we think of MVC, /foo would represent the controller Foo; but knowing that /foo;v=1.0 represents a resource other than /foo, a different controller should be requested?

  • @Andersoncarloswoss guy I searched in the reference and I don’t know ; point and comma in the url, in which section is in rfc3986 is the ; ? excuse my question

  • @Dorathoto Path’s own 3.3 hit, in the last paragraph, stating that ; and = are reserved characters and are used to determine the parameters of a segment of the path. Even if you analyze the URL with Python, the parameters are correctly identified: https://ideone.com/ax3ey6

  • 2

    This question/answer is being discussed at the Meta.

Show 6 more comments

8


What are the path Parameters of a URI and its function?

It is first necessary to understand the concept of segments of path. Segments of path are parts that make up the value of path of a URI, separated by a bar (/). For example, considering the following URI:

https://localhost/admin/users/edit/woss

The segments of path would be admin, users, edit and woss. The section defining the specifications of the path and segments of path is the Section 3.3 of RFC 3986. Quoting:

path          = path-abempty    ; begins with "/" or is empty
              / path-absolute   ; begins with "/" but not "//"
              / path-noscheme   ; begins with a non-colon segment
              / path-rootless   ; begins with a segment
              / path-empty      ; zero characters

path-abempty  = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty    = 0<pchar>

segment       = *pchar
segment-nz    = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
              ; non-zero-length segment without any colon ":"

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

Analyzing the above definitions, it is possible to conclude that the specification itself does not consider the characters ;, , and =, defining the parameter as part of the segment.

That said, it is possible to define, then, the parameters of the path. The parameter of path is one way to provide more information on the path for the application, separating this from own path or other parameters by a semicolon (;), may use the characters of equal (=) and comma (,) to construct the value of the parameter. For example, consider the following URI:

https://localhost/api;version=1.0,2.0

We should consider that version=1.0,2.0 is the parameter of path, separated from it by ;, so-called version, possessing two values: 1.0 and 2.0. What this represents will depend solely on the resource requested by this URI, as well as the Leonan Carvalho commented in his reply, on the fact of path be a opaque value. By way of example, this URI could be requesting a public API that has different versions available and, with the parameter of path, the client is specifying which versions he accepts to handle his request.

A question that may arise at this time is about the difference between the parameters of path and the query URI, because it would be possible to do something equivalent by doing:

https://localhost/api?version=1.0,2.0

The two concepts are similar and have an almost identical proposal: provide a means for the client to pass more information of the requested resource to the server. The main difference is semantic: the information provided by query are associated with the URI as a whole, while the parameters of the path are associated with the segments to which they belong. In the URI https://localhost/api?version=1.0,2.0 we must understand that the value version=1.0,2.0 is associated with https://localhost/api, that is, to the full URI, while at https://localhost/api;version=1.0,2.0 the same value will be associated only to api, which is the segment of path to which the parameter is.

In this way, it is possible to indicate different parameter values to different segments in the URI without interference between them:

https://localhost/api;version=1.0/users/create;mode=strict

In the URI above, the parameter version=1.0 will be associated with the segment api, while the parameter mode=strict will be associated with the segment create. Even, the names of the parameters could be the same without interfering with each other:

https://localhost/maps;version=0.1/api;version=1.2/location

The application would be (or should be) able to identify that version=0.1 refers to the resource represented in the segment maps while varsion=1.2 refers to the resource represented by the segment api. Something similar would not be possible to do only with query, except rename attribute names:

https://localhost/maps/api/location?version_maps=0.1&version_api=1.2

Another example that approaches everyday life to facilitate understanding would be the search for products in a virtual store through various filters. We imagine that the present user do the search for size M t-shirts and size 40 pants. A possible URI representing this resource could be:

https://localhost/products/search/camisetas;tamanho=M/calças;tamanho=40

A URI that defines the parameters represents a resource other than the URI that does not have the parameters? This is, /foo;v=1.0 is a different resource from /foo?

The answer is: depends, but be very careful with that. Therefore, as already mentioned, the path of the URI is an opaque value and thus what exactly it represents is defined only in the implementation of the application. It can represent a different resource as well as represent the same resource, with a parameter that modifies its behavior. Care should be taken because, in particular, I have never seen an application that made use of the parameters of path and, considering the implementations of routers and dispatchers most common, especially under the MVC architecture, no (or almost no) application does the processing of parameters in the segments of the path, thus considering different resources. The format of the URI commonly considered is /controller/action/(parameters)?, then informing a URI as /users/create;mode=strict, the application would possibly consider create;mode=sctrict as being the action to be executed, generating error.

To quote, in PHP:

<?php

$url = "https://localhost/products/search/camisetas;tamanho=M/calças;tamanho=40";

print_r(parse_url($url));

Results in:

Array
(
    [scheme] => https
    [host] => localhost
    [path] => /products/search/camisetas;tamanho=M/calças;tamanho=40
)

See working on Ideone.

And in Python:

from urllib.parse import urlparse

url = "https://localhost/products/search/camisetas;tamanho=M/calças;tamanho=40"

print(urlparse(url))

Results in:

ParseResult(scheme='https', netloc='localhost', path='/products/search/camisetas;tamanho=M/calças', params='tamanho=40', query='', fragment='')

Note: the function urlparse Python is able to correctly identify the parameter of the last segment of path.

See working on Ideone.

  • 1

    This question and answers are being discussed at the Meta. Comments on the content of the reply and possible reasons for -1 are certainly welcome here.

  • Free downvote is simply annoying, it shows how people don’t understand that their answers are wrong and start attacking other answers because they simply feel victimized without being.

  • Just for the record I gave +1 in this answer, it does not invalidate my and brings a different approach, more " within the code."

5

The only way to interpret what is in an RFC is to go back to it and look for the specific definition by searching within its typology the meanings for each of the elements.

Note section 3.3, which defines Path :

In addition to point segments in Path hierarchical, a segment of Pathis considered opaque by generic syntax. Applications of URI production usually use the reserved characters allowed in a segment to delimit subcomponents [schema-specific metadata] or specific transfer. For example, semicolon (";") and matching reserved characters ("=") are often used to delimit parameters and values of parameters applicable to this tracking. The reserved character of the comma (",") is often used for similar purposes. For example, a URI to produce can use a segment as "name; v = 1.1" for indicate a reference to version 1.1 of the "name", while another may use a segment as "name, 1.1" to indicate it. The types of parameters can be defined by semantics specific to the schematic, but in most cases the syntax of a parameter is specific for the implementation of the URI dereference algorithm. (literal translation)

We can say then that path Parameters are elements of the Path URI for specific implementation of the dereference algorithm, i.e., interpreting the value contained.

In programming, desreferiar is access information at the address contained by a pointer. The syntax of the dereference varies between the computer languages.

Answering the question,

path Parameters of a URI and what its function is?

In the case of the URI, path Parameters has the function of extending information from a Path tracking in order to add extra information (metadata or subcomponents) is a resource. How the Path implementation is opaque, the manner in which it will be used and interpreted depends exclusively on the program that makes the schema desference.

A URI defining the parameters represents a resource other than URI that does not have parameters? That is, /foo;v=1.0 is a resource different from /foo? [v=1.0]

Yes, they are different, in the first case "foo" has the metadata v with value 1.0, and in the second the whole URI has a string quetry parameter v with value 1.0.

By converting to a JSON for example we would have:

  • /foo;v=1.0

    { "foo": { v: 1.0 } }

and

  • /foo? v=1.0

    { "foo":null, "v": 1.0 }

But this interpretation for JSON is relative, since " in most cases the syntax of a parameter is specific for the implementation of the URI dereference algorithm. " That is, how the synchronisation of the URI is interpreted depends exclusively on the software that makes the reference.

For example, note the Generic Enabler API of Fiware called "Orion Context Broker", in Specifications>Geographical Queries

Geographical queries are specified using the following Parameters: georel is intended to specify a Spatial Relationship (a predicate) between matching entities and a Reference Shape (Geometry). It is composed of a token list separated by ';'. Example:

georel=near;maxDistance:1000

Although the syntax of the API schema dereference model was imprecised in Query instead of Path the schema could have been impregnated as a Path geo parameter received some subcomponents (maxDistance 1000 ) that allowed for more aggregate use of the api since it is possible to form a more complex Shema, for example:

georel=coveredBy&geometry=polygon&coords=25.774,-80.190;18.466,-66.118;32.321,-64.757;25.774,-80.190

Bringing this logic to a model that is used exclusively Path, we could model the schema as follows:

/api/geoquery/(geoparams+)

That would allow calls like this:

/api/geoquery/georel;type=near;maxDistance:1000

or

/api/geoquery/georel;type=coveredBy;geometry=polygon;coords=25.774,-80.190;18.466,-66.118;32.321,-64.757;25.774,-80.190

Browser other questions tagged uri

You are not signed in. Login or sign up in order to post.