We know that it is possible to pass parameters in the path component of URIs using the syntax ;param=value. I wonder what this is good for, taking into account that parameters can also be passed in the query component.
The Wikipedia article doesn't even mention the possibility of including parameters in the path component.
Another site mentions this possibility but it also adds that it is almost never used:
Each of the path segments can contain parameters which are separated from the segment by a ; (semi-colon) character e.g.:
http://www.blah.com/some;param1=foo/crazy;param2=bar/path.html
The URL above is perfectly valid, although this ability of path segments to hold parameters is almost never used (I've never seen it personally).
I found an explanation on Stackoverflow "when to use #QueryParam vs #PathParam" but it seems to me that any parameters could be passed in the query component, making path parameters redundant. And above all, I don't have an idea why somebody would use the above syntax to pass parameters in the URI.
The example quoted above also raises the question whether param1 and param2 have anything to do with some and crazy, respectively. Or why is it useful that we can include parameters in the path component?
Thank you in advance.
Related
I am trying to use the Watson REST APIs to add examples to an Intent for Watson. Before I call the Create Endpoint I call the Get Example endpoint with the intent and example.
When I call the Get Example endpoint with the word "fine" it returns a 404. Then when I try to Create an example it returns a 400 response
{"error":"Unique Violation: The value \"fine\" already exists"}
This is happening because we already have an example "Fine" (notice the first letter is capital).
How can I prevent this? Are there best practices to store examples in all lower case? Or should I just catch the 400 exception and look at the error.
Violation error means it didn’t update. So you can certainly check for that to take action. Although I personally recommend looking for the related item first to avoid the error.
Coding convention recommendations. These formats are used to easily recognize what is referenced in code and if an identifier is missed.
For example is this below an intent, entity or context variable?
accountingPayBillCode
Intents
All caps, spaces as underscores.
#ACCOUNTING_PAY_BILL
The examples (questions) should be entered untouched as how you received them. Do not attempt to fix spelling / grammar errors.
Example:
I need to pay my bill. Can yuo help me?
Entities
CamelCase with first word capitalized. The value should be all lowercase, and avoid multiple words (but must be meaningful).
#AccountDetail:code
The reason to avoid multiple words as the value is that you can end up with something like this.
#AccountDetail:(part number)
It makes it more prone to a mistake.
Synonyms should also be stored all in lower case.
Context variables.
Always reference using the $ prefix. Use camelCase with first character lowercase.
$accountCode
I'm designing a REST API that supports HTTP GET parameters. In most cases I only accept one value for a parameter. But how should I handle duplicate parameters?
For example, Stack Overflow accepts a GET param tab:
http://stackoverflow.com/?tab=hot
http://stackoverflow.com/?tab=featured
Duplicate parameters are allowed, passing both values is correct:
http://stackoverflow.com/?tab=hot&tab=featured
What should I do? Just go with the first value, thus silently ignoring other values (what SO does) or return an error stating only one value is allowed? In the latter case, what error should I return with what status code (409 Conflict, perhaps)?
I agree with VKSingla that this is a design decision, therefore there is no correct answer only opinions in this matter.
If you ask me I would make a 'strict' API and just throw an error (I would make sure that it is a clear error and not just a random code which doesn't help the user). I prefer this strict approach because if usercode is adding the same param twice it will likely be a bug somewhere in the users code. Revealing this bug as early as possible helps the user finding the bug asap.
If you choose to go with ignoring the other parameters then make sure that the user knows this behavior. For example document 'all duplicate parameters after the first will be ignored'. Undocumented 'magic behavior' like this can make code pretty damn hard to debug.
This is a design decision. Its your API design on how you want it to function.
If you choose to ignore any one , then the question is which one ?
So, it is simply a conflict. or else
your API can respond with combined data, but the request for that should be like this
https://stackoverflow.com/?tab=hot,featured
Also refer this question Extra Query parameters in the REST API Url
We are building an API in-house and often are passing a parameter with multiple values.
They use: mysite.com?id=1&id=2&id=3
Instead of: mysite.com?id=1,2,3
I favor the second approach but I was curious if it was actually incorrect to do the first?
I'm not an HTTP guru, but from what I understand there's not a definitive standard on the query part of the URL regarding multiple values, it's typically up to the CGI that handles the request to parse the query string.
RFC 1738 section 3.3 mentions a searchpart and that it should go after the ? but doesn't seem to elaborate on its format.
http://<host>:<port>/<path>?<searchpart>
I did not (bother to) check which RFC standard defines it. (Anyone who knows about this please leave a reference in the comment.) But in practice, the mysite.com?id=1&id=2&id=3 way is already how a browser would produce when a form contains duplicated fields, typically the checkboxes. See it in action in this w3schools example page. So there is a good chance that the whatever programming language you are using, already provides some helper functions to parse an input like that and probably returns a list.
You could, of course, go with your own approach such as mysite.com?id=1,2,3, which is not bad at all in this particular case. But you will need to implement your own logic to produce and to consume such format. Now you may or may not need to think about handling some corner cases by yourself, such as: what if the input is not well-formed, like mysite.com?id=1,2,? And do you need to invent yet another separator, if the comma sign itself can also be a valid input, like mysite.com?name=Doe,John|Doe,Jane? Would you reach to a point that you will use a json string as the value, like mysite.com?name=["John Doe", "Jane Doe"]? etc. etc.. Your mileage may vary.
Worth adding that inconsistend handling of duplicate parameters in the URL on the server is may lead to vulnerabilities, specifically server-side HTTP parameter pollution, with a practical example - Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc.
in your first approach you will get an array of querystring values but in second approach you will get a string of querystring values.
I guess it depends on technology you use, how it becomes convenient. I am currently standing in front of the same question using currency=USD,CHF or currency=USD¤cy=CHF
I am using Thymeleaf and using the second option makes it easy to work, I can then request something like: ${param.currency.contains(currency.value)}. When I try to use the first option it seems it takes the "array" like a string, so I need to split first and then do contain, what leads me to a more mess code.
Just my 50 cents :-)
I have a template class that grabs HTML and basically returns html to the caller. How do I test the caller using PHP Unit? Do I just assertTrue(is_string(call_function))? It seems like a stupid test, and I thought I may be testing it improperly.
Is the returned HTML supposed to be well-formed? If so you could validate it.
And/or if there is always supposed to be a certain node, or string of text, present you could check for its existence. Using strpos, regexes, or a proper DOM parser.
This StackOverflow question gives you some ideas for ways to parse and query your HTML: How do you parse and process HTML/XML in PHP?
More generally, the way I usually approach how to test a function that returns a string is to use:
$html=call_function();
$this->assertEquals("dummy",$html);
Then it fails, but tells me the correct output, so I paste that in:
$html=call_function();
$expected=<<<EOD
<html>
...
</html>
EOD;
$this->assertEquals($expected,$html);
If it fails again I then study the differences between the two correct answers I have. If this is a good unit test should they really even be different? Do I want to use a mock object to replace some uncontrollable aspect of the system? (E.g. if the HTML it is returning is google search results, then maybe I want a mock object to simulate calling google, but always return exactly the same search results page.)
If the only differences are timestamps I might use regexes to hunt-and-destroy them, to give me a string that should always be the same, e.g.
$html=preg_replace('/\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/','[TIMESTAMP]',$html);
ADDITION
If the HTML string is very big, one alternative is to use md5() to reduce it to a short string. This will still warn you when something breaks, but the (big) downside is when it breaks you won't know where. If you are concerned about that then it is better to use the DOM approach (or its poor cousin, regexes) to just cherry-pick a few key parts of the HTML to test.
I have problem with Jax-rs #Path variable, I need to differentiate the following two pathparams
#Path({domain}/{id})
#Path({domain}/{filename})
sample url for both:
1. http://localhost:8080/in.com/lrth09erdfgwe
2. http://localhost:8080/in.com/lrth09erdfgwe.xml
I think we need to use regex in pathparam! I tried it but failed to get it!
I'm using this application in Resteasy integration with spring-mvc.
Plz advice on this issue!
Cheers!
You control the matching of path parameter by putting inside the parameter a colon and then an RE pattern to match it, like this (where the RE is .+[.].+, which matches anything so long as it has at least one dot somewhere in the middle):
#Path("{domain}/{filename:.+[.].+}")
I use this in one of my services (which uses Apache CXF, but I believe this is a feature of all JAX-RS implementations). Have a care though! You can match path separators with this, which can make things very confusing. (I think you might be better to change the structure of the URIs so that there is no ambiguity, e.g., {domain}/id/{id} and {domain}/files/{filename}. I bet your clients will grok that much more rapidly.)