When I fetch from a dStore the URL looks something like this
http://localhost/rest/dojo?department=sales
which works fine. If I then click in the header of the dGrid the sent URL looks like this.
http://localhost/rest/dojo?department=sales&sort(+id)&limit(25)
Shouldn't it send &sort=+id&limit=25? I am using Java and Spring for the backend and it expects the parameters to be formatted this way. Right now I can not receive the extra parameters. Is there a way to get it to send the parameters the way Spring is expecting them?
sort(...) and limit(...) are the default behaviors of dstore/Request (which Rest extends), but these can be customized via sortParam for sort, and useRangeHeaders or rangeStartParam and rangeCountParam for range.
For example, to result in &sort=+id&limit=25 as you requested, you could set up your store as follows:
var store = new Rest({
target: '...',
sortParam: 'sort',
rangeStartParam: 'offset',
rangeCountParam: 'limit'
});
I've additionally assumed above that offset is the GET parameter you'd want to use to indicate what record to start at when requesting ranges. Generally if you're not using range headers (useRangeHeaders defaults to false) and you want to set a count GET parameter, you'll also need to set a start GET parameter.
These properties are listed in the Request Store documentation.
Related
I have a "copy data" activity making a REST call to get some data in json format. The data should then be transfered to a SQL database.
The problem is I can only get a certain amount of data for the specified HTTP request. For this I need to implement pagination rules, and I have tried to understand this documentation: https://learn.microsoft.com/en-us/azure/data-factory/connector-rest#pagination-support
The HTTP response returns the absolute URL for the next request in the header, with the field named "Link". As I can see in the documentation, it is supposed to be possible to get the value from "Link" and put it into a pagination rule.
As stated in the documentation:
Next request’s absolute or relative URL = header value in current response headers
It says supported pagination keys are AbsoluteUrl, with the value of this should be set like this:
Headers.response_header OR Headers['response_header']
Where the response_header is defined like this in the docs:
"response_header" is user-defined which references one header name in the current HTTP response, the value of which will be used to issue next request.
What I can't seem to understand is how this "response_header" can be set to reference the HTTP response header value of "Link".
You need to replace the 'response_header' placeholder with your header name.
In your case - 'Link'
Or in code editor:
"paginationRules": {
"AbsoluteUrl": "Headers['Link']"
}
Scenario : I need to verify the logs response on server on the basis of Tracking-Id.
I had passed the tracking-id using 'header.js' file, here i define metod which get the unique UUID for every request and passed in header.
Now I need that header value to passed in some method to get logs only for specific Tracking-Id
Is there any way to achieve this in karate?
Yes, you can use karate.set('someVarName', uuidValue) in JS and then back in the feature you will be able to: * print someVarName.
EDIT: please see this commit for an example: link
Is there a way to pass a specific UI language to the registration page? This is coming from the website and I want it to be the defaut option.
you can send the culture with these headers
c=...
uic=...
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.AspNetCore/AspNetCore/Localization/AbpLocalizationHeaderRequestCultureProvider.cs#L12
and for MVC use culture parameter like below
/register?culture=tr
must be the first parameter of the query string
and last option; you can always override AbpUserRequestCultureProvider
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.AspNetCore/AspNetCore/Localization/AbpUserRequestCultureProvider.cs
UPDATE:
According to the implementation it accepts query string parameters as culture like below
?culture=es-MX&ui-culture=es-MX
See https://github.com/aspnetboilerplate/aspnetboilerplate/issues/2103
If you look at the request headers sent by the browser, it includes "Accept-Language". It can look something like this:
en-US,en;q=0.9,es-419;q=0.8,es;q=0.7
Generally, the preference runs in descending order, so here, the browser is saying it prefers U.S. english before anything else. More here about what the q values mean: What is q=0.5 in Accept* HTTP headers?
You can access this value through in the controller.
Request.Headers["Accept-Language"]
I'm writing a simple API, and building a simple web application on top of this API.
Because I want to "consume my own API" directly, I first Googled and found this answer on StackOverflow which answers my initial question perfectly: Consuming my own Laravel API
Now, this works great, I'm able to access my API by doing something like:
$request = Request::create('/api/cars/'.$id, 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());
This is great! But, my API also allows you to add an optional fields parameter to the GET query string to specify specific attributes that should be returned, such as this:
http://cars.com/api/cars/1?fields=id,color
Now the way I actually handle this in the API is something along the lines of this:
public function show(Car $car)
{
if(Input::has('fields'))
{
//Here I do some logic and basically return only fields requested
....
...
}
I would assume that I could do something similar as I did with the query string parameter-less approach before, something like this:
$request = Request::create('/api/cars/' . $id . '?fields=id,color', 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());
BUT, it doesn't seem so. Long story short, after stepping through the code it seems that the Request object is correctly created (and it correctly pulls out the fields parameter and assigns id,color to it), and the Route seems to be dispatched OK, but within my API controller itself I do not know how to access the field parameter. Using Input::get('fields') (which is what I use for "normal" requests) returns nothing, and I'm fairly certain that's because the static Input is referencing or scoping to the initial request the came in, NOT the new request I dispatched "manually" from within the app itself.
So, my question is really how should I be doing this? Am I doing something wrong? Ideally I'd like to avoid doing anything ugly or special in my API controller, I'd like to be able to use Input::get for the internally dispatched requests and not have to make a second check , etc.
You are correct in that using Input is actually referencing the current request and not your newly created request. Your input will be available on the request instance itself that you instantiate with Request::create().
If you were using (as you should be) Illuminate\Http\Request to instantiate your request then you can use $request->input('key') or $request->query('key') to get parameters from the query string.
Now, the problem here is that you might not have your Illuminate\Http\Request instance available to you in the route. A solution here (so that you can continue using the Input facade) is to physically replace the input on the current request, then switch it back.
// Store the original input of the request and then replace the input with your request instances input.
$originalInput = Request::input();
Request::replace($request->input());
// Dispatch your request instance with the router.
$response = Route::dispatch($request);
// Replace the input again with the original request input.
Request::replace($originalInput);
This should work (in theory) and you should still be able to use your original request input before and after your internal API request is made.
I was also just facing this issue and thanks to Jason's great answers I was able to make it work.
Just wanted to add that I found out that the Route also needs to be replaced. Otherwise Route::currentRouteName() will return the dispatched route later in the script.
More details to this can be found on my blog post.
I also did some tests for the stacking issue and called internal API methods repeatedly from within each other with this approach. It worked out just fine! All requests and routes have been set correctly.
If you want to invoke an internal API and pass parameters via an array (instead of query string), you can do like this:
$request = Request::create("/api/cars", "GET", array(
"id" => $id,
"fields" => array("id","color")
));
$originalInput = Request::input();//backup original input
Request::replace($request->input());
$car = json_decode(Route::dispatch($request)->getContent());//invoke API
Request::replace($originalInput);//restore orginal input
Ref: Laravel : calling your own API
I tend to use dojox.data.JsonRestStore as my grid's store, but I am always failed to access struts2 action, I am unfamiliar in REST, is it only can be used in servlet rather than struts2, etc.
Currently, My project is using struts2 + spring as backend skill and dojo as front-side skill, have you any ways for me to make dojox.data.JsonRestStore access a structs2 action class?
Thanks in advance.
to get the data, all you need is an HTTP GET that returns an array of JSON objects. The return value from the action must be a string with something like:
[
{
"penUser":"Micha Roon",
"submitTime":"12.03 13:20",
"state":"Eingang",
"FormNumber":"001001"
},
{
"penUser":"Micha Roon",
"submitTime":"12.03 13:20",
"state":"Eingang",
"FormNumber":"001001"
}
]
If you want to be able to update objects you have to have a method that reacts to PUT with the same URL as the one you used for GET and if you need to delete, DELETE will be used. The important part is that it must be the same URL.
In order to have JsonRestStore pass the ID in a GET parameter instead of appending it to the URL, you could specify the URL like so:
target:"services/jsonrest/formstore?formId="
When you call yourStore.get("123") the request will try to get http://yourserver:port/AppContext/services/jsonrest/formstore?formId=123
REST is nothing more than a convention.
You can use a RESTFull API like jersey.java.net in order to make your life easier and your URL more RESTFull.