We have a URL https://www.mylink.com/est?myId=4d22b9d0-4ff2-46c3-9343-945304dfea93
The above request also contains post data:
myId=4d22b9d0-4ff2-46c3-9343-945304dfea93
How can I parameterize this as the url and post data both contain same value but its dynamic. Also, how may I store it in a variable to use it somewhere else as well?
In order to be able to use it in URL and request body you need to extract it somewhere somehow, this dynamic ID is probably associated with this or that user account so my expectation is that after logging in you should see this ID somewhere in the response.
The process is known as correlation and there is a plenty of information over the web about handling dynamic requests in JMeter. There are also solutions which provide semi or fully automated correlation of the dynamic parameters like Correlations Recorder Plugin for JMeter or JMeter Proxy Recorder
If you just need to generate an unique GUID-like structure - you can do it using __UUID() function
I need to secure url so there are 2 possible ways to access:
the client has a specific ip
or the client needs to be logged in
So, I need to give two rule for a single URL, using something like the or method below:
.antMatchers("/url/**").authenticated().or().hasIpAddress("192.bla.bla")
Is there a way to accomplish that?
You can combine them using SPEL.
String expression = "hasIpAddress('127.0.0.1') or hasRole('ROLE_USER')";
http
.authorizeRequests()
.antMatchers("/home").access(expression)
Every URL ends with the same pattern, "Part-123456789" where the "Part" is a constant and the "123456789" is a part number. I want to run an adwords campaign targetting every part # and directing to the unique url for that part. Is there a simple way to do this?
Note: Adwords Editor is giving me ambiguous rowtype errors whenever I try to upload the keywords and URL's together in the same line of a .csv file.
The available value track parameters for AdWords tracking templates offers both the keyword ID and matched keyword:
https://support.google.com/adwords/answer/6305348?co=ADWORDS.IsAWNCustomer%3Dfalse&hl=en
You could use this to determine the part number in the URL but it may require some mapping in the content management system.
I am receiving HTTP/SOAP request with some query parameters. Those query parameters are in repeated format as key=value as /q=key1=value1&key2=value2 etc...
I would like to retrieve all the keys from above URL and check if they are valid or not.
1. Is there any way to define global array which can hold these keys
2. How to validate if keys are present or not. Does ESB supports java "contains" API ?
I believe you are doing a GET request..
You can retrieve all the query parameters in a sequence.
eg:
For a request url; http:// localhost:8280/getSimpleQuote?symbol=IBM
<property name="symbol" expression="$url:symbol"/> will return the symbol 'IBM'.
After getting all keys, you can validate them
you can get the query parameters with the xpath expression get-property{'uri.var.xxx'} with xxx is the name of the query parameter you need to get.
When a resource is defined with a URL mapping, only those requests that match the given URL mapping will be processed by the resource. Alternatively one could configure a resource with a URI template. A URI template represents a class of URIs using patterns and variables. Some examples of valid URI templates are given below.
/order/{orderId}
/dictionary/{char}/{word}
All the identifiers within curly braces are considered variables. A URL that matches the template “/order/{orderId}” is given below.
/order/A0001
In the above URL instance, the variable orderId has been assigned the value “A0001”. Similarly following URL adheres to the template “/dictionary/{char}/{word}”.
/dictionary/c/cat
In this case the variable “char” has the value “c” and the variable “word” is given the value “cat”. When a resource is associated with a URI template, all requests that match the template will be processed by the resource. At the same time ESB will provide access to the exact values of the template variables through message context properties. For an example assume a resource configured with the URI template “/dictionary/{char}/{word}”. If the request “/dictionary/c/cat” is sent to the ESB, it will be dispatched to the above resource and we will be able to retrieve the exact values of the two variables using the get-property XPath extension of WSO2 ESB:
I have a Rails app that needs to expose values from a database as a web service - since I'm using Rails 2.x, I'm going with REST (or at least try). Assuming my resource is Bananas, for which I want to expose several sub-characteristics, consider this:
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
I don't want to search for ID, only name or number. And I have about 7 sub-characteristics to expose. Is this RESTful?
Thanks for any feedback!
What Wahnfrieden is talking about is something called Hypermedia as the Engine of Application State (HATEOAS) - a central constraint of REST as defined by Fielding.
In a nutshell, REST application clients never construct URIs themselves. Instead, they follow URIs provided by the application. So, URI templates such as the ones you're asking about are irrelevent at best. You can make them conform to a system if you'd like, but REST says nothing about how your URIs need to look. You could, if you wanted to, arrange it so that every resource in your system was available from http://example.com/{hash}.
Publishing URI templates, such as the ones you're talking about in your question, introduces tight coupling between your application and clients - something REST is trying to prevent.
The problem with understanding hypermedia-driven applications is that almost nobody implements or documents their "RESTful" systems this way.
It might help to think about the interaction between a human and server via a browser. The human only knows about content and links that the server provides through the browser. This is how a RESTful system should be built. If your resources aren't exposing links, they're probably not RESTful.
The advantage is that if you want to change your URI system, for example, to expose the Banana "Peel" attribute through a query parameter instead of a nested URL, you can do it anytime you'd like and no client code needs to be changed because they're not constructing links for themselves.
For an example of a system that embraces the hypertext-driven constraint in REST, check out the Sun Cloud API.
I would use these:
/banana
/banana/blah
/banana/123
/banana/blah/peel (and /banana/123/peel)
/banana/blah/length (and /banana/123/length)
First, common practice for ReSTful URIs is /object_name/id/verb, with some of those absent (but in that order). Of course, this is neither required nor expected.
If all your names aren't made of digits, you don't have to explicitly have name in /banana/name/blah. In fact, if anything, it would be better to have id as identifier: /banana/id/123/peel. Hope this helps.
Parameters should only be used for form submission.
Also, URI naming schemas is totally unrelated to REST. The point of REST is to make related resources discoverable via hypertext, not out-of-band conventions, and only from a limit number of entry points. So your /bananas/ entry point might provide the summary info for 10 bananas, but it must also provide the URI for each of those bananas' details resources, as well as the URI to get the summary for the next 10 bananas. Anything else is just RPC.
It is good practice in REST to not use query parameters because query parameters don´t belong to a URL and in REST all resources should be addressable through a URL.
In your example /banana/?name=name should be /banana/name because you are referring a concrete resource.
Even I think /banana/?number=number/length is not good REST style, because you are selecting an attribute through a URL when you should retrieve the whole state with /banana/name . A difference could be /customers/1024/address to get the Customer 1024 address record.
HTH.
A more opt form for the route in url having query string is the plural form, as it is possible that multiple items are returned in the result. In this case, bananas, like bananas?color=yellow, sounds more appropriate.
On the other hand, the singular form banana, like banana/123, is good when fetching a specific resource's representation when its identifier is known and query string is not required.