imagine a very simple flow with a HTTP inbound and a body-to-parameter-map. Payload contains something like {prop1=aaa, prop2=eee, prop3=iii}.
My question is, why if I try to access #[payload.prop1] sometimes (and I said sometimes) it gets null value, while #[payload['prop1']] seems to be allways correct?
Those are equivalent, the only different would be that the dot notation also support objects while the key one only support collections.
It's perhaps that the you are using the dot notation with keys that already contain a dot? Like http.status. In those cases you should either escape with 'http.status'.
Related
I have a question about a simple REST API endpoint.
The endpoint can accept a value expressed in EURO then returns the corresponding value in DOLLAR, conversely it can accept a value in DOLLAR an return the value in EURO.
I would like to know how I should name this endpoint to respect REST API endpoint naming conventions and best practices.
So far, I have thought about:
-convert-euro-dollar (Probably bad because it uses a verb)
-euro-dollar (Good option?)
Thanks in advance!
I would like to know how I should name this endpoint to respect REST API endpoint naming conventions and best practices.
REST doesn't care what naming conventions you use for your resource identifiers. (Hint: URL shorteners work.)
See Tilkov 2014.
The motivation for choosing "good" resource identifiers is much the same as the motivation for choosing "good" variable names -- the machines don't care, therefore you have extra degrees of freedom that you can use to make things easy for some people.
Possible people you might want to make things easy for: folks looking at resource identifiers in their browser history, operators looking at identifiers in HTTP access logs, writers trying to document the API, etc.
https://www.merriam-webster.com/dictionary/put
Verbs are fine; notice that this URL works exactly the way that you and your browser expect it to, even though the identifier includes a HTTP method.
As suggested by https://stackoverflow.com/a/48692503/19060474 and https://stackoverflow.com/a/10883810/19060474, I would go with one of
GET /dollar/from-euro
GET /euro/to-dollar
GET /currency/usd/from/usd
GET /currency/eur/to/usd
as long as you stay consistent.
Keep in mind, that you should be able to easily deduce from the endpoint what it will likely do. So you should make clear in which direction the conversion will be performed.
With euro-dollar or convert-euro-dollar this is not clearly expressed because one can not determine if the endpoint expects dollar (which dollar by the way, there are quite some variants like USD, AUD, CAD, ...) and converts to EUR or vice versa.
I also suggest you consider using currency codes from the ISO 4217 standard to avoid ambiguity. You can find some of them at https://www.iban.com/currency-codes.
Be aware that answers to this are opinion based, because there is no REST constraint on URI design. All you need is following the URI standards which tells you that the path is hierarchical and the query is non-hierarchical, and that's all. Even that part is sort of flexible.
As of the URI design conventions, I like to describe the operation first and convert it into a verb and a noun. After that I choose HTTP method for the verb and try to describe the rest of it with a noun and attach that second noun to the first one and convert it to an URI template. So I like to name my resources with nouns.
The endpoint can accept a value expressed in EURO then returns the
corresponding value in DOLLAR, conversely it can accept a value in
DOLLAR an return the value in EURO.
Here the operation name would be convertEuroToDollarOrDollarToEuro. I think either we have two operations here convertEuroToDollar and convertDollarToEuro or we need a more general operation name something like convertCurrency and restrict it to the supported currencies, which are Euro and Dollar. Here either I would use POST /conversion to create a new conversion or I would use GET /conversion to read the conversion result.
POST /currency/conversion {"fromCurrency": "EUR", "toCurrency": "USD", "amount": 100}
POST /currency/conversion {"fromCurrency": "USD", "toCurrency": "EUR", "amount": 100}
GET /conversion/{amount}/{fromCurrency}/to/{toCurrency}
GET /conversion/100/EUR/to/USD
GET /conversion/100/USD/to/EUR
GET /currency/conversion?from={fromCurrency}&to={toCurrency}&amount={amount}
GET /currency/conversion?from=EUR&to=USD&amount=100
GET /currency/conversion?from=USD&to=EUR&amount=100
If your service meets the HATEOAS constraint, then this kind of URI structure matters only from service developer perspective, because it is relative easy to figure out the HTTP methods URI templates for the endpoints and bind them to controller methods.
From service consumer or REST client perspective what matters here is the operation name, which is convertCurrency and its parameters: fromCurrency, toCurrency, amount. You need to add these to the documentation and if you can with your actual MIME type attach the metadata to the hyperlink, which represent this operation. So at least do something like:
{
method: "GET",
uri: "/conversion/{amount}/{fromCurrency}/to/{toCurrency}",
type: "convertCurrency"
}
A more advanced solutions would describe the documentation of the convertCurrency operation in a machine readable way. For example Hydra does this: https://www.hydra-cg.com/ and maybe HAL forms can be another solution: https://rwcbook.github.io/hal-forms/ .
When trying to filter by tag, there is a small popup:
I have been looking for logfmt around, but all I can find is key=value format.
My questions are:
Is there a way for something more sophisticated? (starts_with, not equal, contains, etc)
I am trying to filter by url using http.url="http://example.com?bla=bla&foo=bar". I am pretty sure the value exists because I am copy/pasting from my trace. I am getting no results. Do I need to escape characters or do something else for this to work?
I did some research around logfmt as well. Based on the documentation of the original implementation and in the Python implementation of the parser (and respective tests), I would say that it doesn't support anything more sophisticated (like starts_with, not equal, contains). And this is because the output of the parser is a simple dictionary (with no regex involved in the values).
As for the second question, using the same mentioned Python parser, I was able to double-check that your filter looks fine:
from logfmt import parse_line
parse_line('http.url="http://example.com?bla=bla&foo=bar"')
Output:
{'http.url': 'http://example.com?bla=bla&foo=bar'}
This makes me suspect of an issue on the Jaeger side, but this is as far as I could go.
I used to specify VarLenFeature when I want to decode variable-length input feature, but recently I noticed there is a FixedLenSequenceFeature could do the same thing for me, so what's the difference between these two class? and when should I use one instead of the other? I can get nearly nothing from the documentation.
VarLenFeature
FixedLenSequenceFeature
A vendor I use packages their software with AssemblyScript. They provide some infrastructure and I build on top of it.
Accidentally, I changed my double equal signs ("==") to triple equal signs ("===") in a function that performs equality checks on hexadecimal strings. I spent hours ensuring that the values checked are indeed equal and have the same case sensitivity, but nothing could make the if statement enter the branch I was expecting it to enter, except for going back to "==".
And so I ended up here, asking for help. How is "===" different to "==" in AssemblyScript? Is it some quirk of the language itself or the vendor's parser?
Yes. In AssemblyScript tripple equal ("===") compare raw references and skip overloading operator ("=="). See docs.
There are have proposal avoid this non-standard for TypeScript behaviour. You could check and upvote this issue
Following conversion
SELECT to_tsvector('english', 'Google.com');
returns this:
'google.com':1
Why does TSearch2 engine didn't return something like this?
'google':2, 'com':1
Or how can i make the engine to return the exploded string as i wrote above?
I just need "Google.com" to be foundable by "google".
Unfortunately, there is no quick and easy solution.
Denis is correct in that the parser is recognizing it as a hostname, which is why it doesn't break it up.
There are 3 other things you can do, off the top of my head.
You can disable the host parsing in the database. See postgres documentation for details. E.g. something like ALTER TEXT SEARCH CONFIGURATION your_parser_config
DROP MAPPING FOR url, url_path
You can write your own custom dictionary.
You can pre-parse your data before it's inserted into the database in some manner (maybe splitting all domains before going into the database).
I had a similar issue to you last year and opted for solution (2), above.
My solution was to write a custom dictionary that splits words up on non-word characters. A custom dictionary is a lot easier & quicker to write than a new parser. You still have to write C tho :)
The dictionary I wrote would return something like 'www.facebook.com':4, 'com':3, 'facebook':2, 'www':1' for the 'www.facebook.com' domain (we had a unique-ish scenario, hence the 4 results instead of 3).
The trouble with a custom dictionary is that you will no longer get stemming (ie: www.books.com will come out as www, books and com). I believe there is some work (which may have been completed) to allow chaining of dictionaries which would solve this problem.
First off in case you're not aware, tsearch2 is deprecated in favor of the built-in functionality:
http://www.postgresql.org/docs/9/static/textsearch.html
As for your actual question, google.com gets recognized as a host by the parser:
http://www.postgresql.org/docs/9.0/static/textsearch-parsers.html
If you don't want this to occur, you'll need to pre-process your text accordingly (or use a custom parser).