I am building an API endpoint that accepts DateTime as a parameter.
It is recommended not to use : character as part of the URI, so I can't simply use ISO 8601 format.
So far I have considered two formats:
A) Exclamation mark as minute delimiter:
http://api.example.com/resource/2013-08-29T12!15
Looks unnatural and even with clear documentation, API consumers are bound to make mistakes.
B) URI segment per DateTime part:
http://api.example.com/resource/2013/08/29/12/15
Looks unreadable. Also, once I add further numeric parameters - it will become incomprehensible!
Is there standard/convention for for representing date/time in URIs?
I'd use the data interchange standard format.
Check this: http://en.wikipedia.org/wiki/ISO_8601
You can use : in URI paths.
The colon is a reserved character, but it has no delimiting role in the path segment. So the following should apply:
If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.
There is only one exception for relative-path references:
A path segment that contains a colon character (e.g., "this:that") cannot be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name. Such a segment must be preceded by a dot-segment (e.g., "./this:that") to make a relative-path reference.
But note that some encoding libraries might percent-encode the colon anyway.
Related
The Helium API includes several requests that specify an address in "B58" format (examples).
What is the "B58" format, and what API will return a B58 address given a Helium node name?
What is the "B58" format
It is sort of like base64 encoding, but some easily confused characters have been removed from the alphabet. From wikipedia:
Similar to Base64, but modified to avoid both non-alphanumeric
characters (+ and /) and letters that might look ambiguous when
printed (0 – zero, I – capital i, O – capital o and l – lower-case L).
Base58 is used to represent bitcoin addresses.[2] Some messaging and
social media systems break lines on non-alphanumeric strings. This is
avoided by not using URI reserved characters such as +. For segwit it
was replaced by Bech32, see below.
and what API will return a B58 address given a Helium node name?
You want: https://api.helium.io/v1/hotspots/name/:name
From here: https://docs.helium.com/api/blockchain/hotspots/#hotspots-for-name
I think it was added sort of recently, so it likely didn't exist when you asked this question.
I have review multiple instructions on URL-parameters which all suggest 2 approaches:
Parameters can follow / forward slashes or be specified by parameter name and then by parameter value. so either:
1) http://numbersapi.com/42
or
2) http://numbersapi.com/random?min=10&max=20
For the 2nd one, I provide parameter name and then parameter value by using the ?. I also provide multiple parameters using ampersand.
Now I have see the request below which works fine but does not fit into the rules above:
http://numbersapi.com/42?json
I understand that the requests sets 42 as a parameter but why is the ? not followed by the parameter name and just by the value. Also the ? seems to be used as an ampersand???
From Wikipedia:
Every HTTP URL conforms to the syntax of a generic URI. The URI generic syntax consists of a hierarchical sequence of five components:
URI = scheme:[//authority]path[?query][#fragment]
where the authority component divides into three subcomponents:
authority = [userinfo#]host[:port]
This is represented in a syntax diagram as:
As you can see, the ? ends the path part of the URL and starts the query part.
The query part is usually a &-separated string of name=value pairs, but it doesn't have to be, so json is a valid value for the query part.
Or, as the Wikipedia articles says it:
An optional query component preceded by a question mark (?), containing a query string of non-hierarchical data. Its syntax is not well defined, but by convention is most often a sequence of attribute–value pairs separated by a delimiter.
It is also fairly common for request processors to treat a name=value pair that is missing the = sign, as if the it was name=.
E.g. if you're writing Servlet code and call servletRequest.getParameter("json"), it would return an empty string ("") for that last URL in the question.
Let admit that with Jersey I expose 2 queries that are :
/hello/{name}
/hello/goodby
If the user do /hello/goodby, does Jersey guarantie that it is the request "/hello/goodby" that will be chosen and not "/hello/{name}" with the name equals to "goodby" ?
I have case like that in the services that I expose, it seems that static path is always chosen but I'm looking for a kind of confirmation in the documentation and I don't see anything here : https://jersey.github.io/documentation/latest/jaxrs-resources.html#d0e2271
It's not going to be in the documentation. It's going to be in the JAX-RS Spec. Look in the section "3.7.2 Request Matching", and somewhere along in the cryptic mumbo jumbo you will see this:
Sort E using the number of literal characters in each member as the primary key
E being the so far qualified methods based on path. This means that the path with the most literal characters should be prioritized. In your case, that's why /hello/goodbye always wins. goodbye are literal characters, while {name} has zero literal characters, it's a capture group.
That is correct. /hello/goodby is given precedence over /hello/{name} assuming both are at the same level like class or method.
All matching classes are sorted in descending order on the below conditions -
Number of literal characters as primary key
Number of path params as secondary key
Number of regex strings as ternary key.
In your case, you have only literal characters and path params.
/hello/goodby - 12 literal characters and 0 path params.
/hello/{name} - 4 literal characters and 1 path params.
According to the sorting algorithm, /hello/goodby will be before /hello/{name}, and /hello/goodby is the best match.
Let's say, I have a regular expression that checks the validation of the input value as a whole. For example, it is an email input box and when user hits enter, I check it against ^[A-Z0-9._%+-]+#[A-Z0-9.-]+\.[A-Z]{2,4}$ to see if it is a valid email address.
What I want to achieve is, I want to intercept the character input too, and check every single input character to see if that character is also a valid character. I can do this by adding an extra regular expression, e.g. [A-Z0-9._%+-] but that is not what I want.
Is there a way to extract the widest possible range of acceptable characters from a given regular expression? So in the example above, can I extract all the valid characters that are defined by the original regular expression (i.e. ^[A-Z0-9._%+-]+#[A-Z0-9.-]+\.[A-Z]{2,4}$) programmatically?
I would appreciate any help or hint.
P.S. This is project for iOS written in Objective-C.
If you don't mind writing half a regex parser, certainly. You would have to be able to distinguish literals from meta-characters and to unroll/merge all character classes (including negated character classes, and nested negated character classes, if you regex flavor supports them).
If NSRegularExpressions doesn't come with some convenience method, I cannot imagine how it would be possible otherwise. Just think about ^. When it is outside of a character class, it's a meta-character that you can ignore. If it is inside a character class, it's a meta-character, that negates the character class unless it is not the first character. - is a meta-character inside character classes, unless it is the first character, the last character, or right after another character range (depending on regex flavor). And I'm not even speaking about escaped characters.
I don't know about NSRegularExpressions, but some flavors also support nested character classes (like [a-z[^aeiou]] for all consonants). I think you get where I am going with this.
I recently read some of : https://www.rfc-editor.org/rfc/rfc6570#section-1
And I found the following URL template examples :
GIVEN :
var="value";
x=1024;
path=/foo/bar;
{/var,x}/here /value/1024/here
{#path,x}/here #/foo/bar,1024/here
These seem contradictory.
In the first one, it appears that the / replaces ,
In the 2nd one, it appears that the , is kept .
Thus, I'm wondering wether there are inconsistencies in this particular RFC. I'm new to these RFC's so maybe I don't fully understand the culture behind how these develop.
There's no contradiction in those two examples. They illustrate the point that the rules for expanding an expression whose first character is / are different from the rules for expanding an expression whose first character is #. These alternative expansion rules are pretty much the entire point of having a variety of different magic leading characters -- which are called operators in the RFC.
The expression with the leading / is expanded according to a rule that says "each variable in the expression is replaced by its value, preceded by a / character". (I'm paraphrasing the real rule, which is described in section 3.2.6 of that RFC.) The expression with the leading # is expanded according to a rule that says "each variable in the expression is replaced by its value, with the first variable preceded by a # and subsequent variables preceded by a ,. (Again paraphrased, see section 3.2.4 for the real rule.)