What is this strange path syntax?-CodePudding

One of my colleagues uses = as shown below for path variables and it surprisingly (to me) works. However, I have never seen examples of it in any tutorials.

@GetMapping("/getCustomFieldBy={portId}")
public ResponseEntity getMempools(@PathVariable Long portId) {
    return ResponseEntity.ok(customFieldService.findByPortId(portId));
}

I expect a / inside the pathname. Is there a name for this syntax or is it even standard? How do I look it up?

CodePudding user response：

It is not a strange syntax, it's a valid and literal mapping of the = character. These are examples of valid endpoints that the mapping intercepts:

localhost:8080/getCustomFieldBy=8009
localhost:8080/getCustomFieldBy=15123

It is not a standard nor a convention to use =. A typical REST endpoint would look rather like this:

localhost:8080/customField?port=8009

CodePudding user response：

This is in no way following the REST standards.

First, the path should not represent commands or actions (unless there is really no other way) but resources instead. This means you should avoid verbs in the path, buts nouns instead. In your case, something like /custom-fields seems appropriate.

Second, using = in the path is not usual or standard. You should use it only in query parameters.

Finally, in this case, since portId does not seem to be the custom-fields ID I would suggest you use a query parameter to get the port ID as follows: /custom-fields?port_id=123.

CodePudding user response：

TL;DR: it's just an ordinary URI, where the designer decided to include an equals sign in the spelling of a path segment.

The URI Template here describes a simple string expansion. Although we commonly see expansions that occupy an entire path segment (ex: /{portId}/), that isn't required - string expansions can also be used to describe part of a path segment.

Valid path segments in URI are defined by RFC 3986. Summarizing the production rules

segment       = *pchar
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / " " / "," / ";" / "="

So the equals sign is just another letter, as far as standardized parsing of URI path segments is concerned.

Key=Value spellings are common in the query part of a URI; for example, that's what you see when an HTML form copies its inputs into the URI.

In the 1990s, TBL described using a similar convention for describing matrix spaces.

matric URI parsing is not a feature of the web. This is just something which could have been. -- TBL, 2001

The canonical example:

//moremaps.com/map/color;lat=50;long=20;scale=32000

But breaking out key/value pairs this way doesn't mean anything, in the sense that we don't have a common understanding that general purpose components can use to do something interesting.

Note that level 3 and level 4 URI templates do have an expansion for semi-colon prefixed key value pairs

x     := "1024" 
y     := "768"

{;x,y}                ;x=1024;y=768

keys  := [("semi",";"),("dot","."),("comma",",")]

{;keys*}              ;semi=;;dot=.;comma=,

Not an exact match for your example, which lacks the leading semi-colon.