I have a GET API url something like: /api/countries.
I want to search from it using multiple parameters like name& code... For that, I will do /api/countries?name=pak&code=92
But what if I want to use OR in url params e.g. /api/countries?name=pakORcode=92
If you use OR as you have shown in your question then it will not work (name will contain the value pakORcode=92). If this is something that you would consider doing then you could use explode to split into key-value pairs around each OR.
You could maybe also have a third variable, method. You could set this to either AND or OR, then you'd know what method to use?
Hope this helps
What you describe is not a regular API call.
you can solve this in 2 ways
Create the logic in your controller where you implement the or statement
Implement the ODATA REST protocol.
I would prefer ODATA. Entity framework has support for this and you can even implement this on your own created lists.
In ODATA you can use filter expressions:
filter=name eq 610 or code eq 615
https://msdn.microsoft.com/en-us/library/hh169248(v=nav.90).aspx
Related
I know how to call specific scenario from another feature file and pass parameters along. But is there a way I can do it while checking for condition using 'if'?
For instance:
* if (role=="SME"||role=="BA") karate.call('classpath:rough/utility.feature#checkDisabled'){element: #(elem)}
If this is the wrong implementation as what I get from the console. Please suggest me a way how can i achieve this in karate?
Thanks
When you use karate.call() put the second argument inside the round brackets. This is pure JS and "Karate-style" embedded expressions will not work.
* if (role=="SME"||role=="BA") karate.call('classpath:rough/utility.feature#checkDisabled', {element: elem})
Please take some time to read this part of the docs: https://github.com/karatelabs/karate#call-vs-read
While designing the API with with the team a suggestion was forwarded in regards to some complex query parameters that we sent which need to be encoded as objects, arrays of objects, etc. Suppose I have a route GET /resource/ and I want to apply a set of filters directly in the query params. The object literal structure of this filter would be something like
filter: {
field1: {
contains: 'value',
notin: ['value2', 'value3']
},
field2: {
greaterThan: 10
}
}
Encoding this in the url, via a query string parser such as the qs node module that express.js uses internally, would be cheap on the backend. However 1) The generated url is very hard to read, if a client wants to connect with the API he would need to use an encoding library and 2) I don't think I ever encountered the use of query params like this, it looks a little bit of overengineered and I'm not sure how used it is and if it is really safe.
The example above would yield query params such as:
GET /resource/?field1%5Bcontains%5D=value&field1%5Bnotin%5D%5B0%5D=value2&field1%5Bnotin%5D%5B1%5D=value3&field2%5BgreaterThan%5D=10
Does this practice of sending url query parameters that happen to be complex objects have some standards or best practices?
We implemented a different solution for filtering, when the list of possible parameters was very long. We ended up doing it in two steps, posting the filter and returning a filter ID. The filter ID could then be used in the GET query.
We had trouble finding any best practices for this.
I'd like to be able to specify a string, let's say
NSString * pathPattern = /api/elements/:id/subelement/:type
and call a simple function
[pathPattern build:#{#":id" => id, #"subelement" => subelement}]
to generate the URL path.
Obviously I can build a simple category to do this, but does something exist that handles such things in a generic way, and maybe has additional useful features for this kind of thing that I haven't thought of at this time?
Yes, RestKit already injects parameters into path patterns. Internally it uses SOCKit to perform this parameterisation.
It actually uses exactly the format you have in the question and where the parameter names match keys on the supplied object for mapping.
The path pattern can also be used during response mapping to take values back out of the request URL.
Inside an Objective-C method, it is possible to get the selector of the method with the keyword _cmd. Does such a thing exist for the names of arguments?
For example, if I have a method declared as such:
- (void)methodWithAnArgument:(id)foo {
...
}
Is there some sort of construct that would allow me to get access to some sort of string-like representation of the variable name? That is, not the value of foo, but something that actually reflects the variable name "foo" in a local variable inside the method.
This information doesn't appear to be stored in NSInvocation or any of its related classes (NSMethodSignature, etc), so I'm not optimistic this can be done using Apple's frameworks or the runtime. I suspect it might be possible with some sort of compile-time macro, but I'm unfamiliar with C macros so I wouldn't know where to begin.
Edit to contain more information about what I'm actually trying to do.
I'm building a tool to help make working with third-party URL schemes easier. There are two sides to how I want my API to look:
As a consumer of a URL scheme, I can call a method like [twitterHandler showUserWithScreenName:#"someTwitterHandle"];
As a creator of an app with a URL scheme, I can define my URLs in a plist dictionary, whose key-value pairs look something like #"showUserWithScreenName": #"twitter://user?screenName={screenName}".
What I'm working on now is finding the best way to glue these together. The current fully-functioning implementation of showUserWithScreenName: looks something like this:
- (void)showUserWithScreenName:(NSString *)screenName {
[self performCommand:NSStringFromSelector(_cmd) withArguments:#{#"screenName": screenName}];
}
Where performCommand:withArguments: is a method that (besides some other logic) looks up the command key in the plist (in this case "showUserWithScreenName:") and evaluates the value as a template using the passed dictionary as the values to bind.
The problem I'm trying to solve: there are dozens of methods like this that look exactly the same, but just swap out the dictionary definition to contain the correct template params. In every case, the desired dictionary key is the name of the parameter. I'm trying to find a way to minimize my boilerplate.
In practice, I assume I'm going to accept that there will be some boilerplate needed, but I can probably make it ever-so-slightly cleaner thanks to NSDictionaryOfVariableBindings (thanks #CodaFi — I wasn't familiar with that macro!). For the sake of argument, I'm curious if it would be possible to completely metaprogram this using something like forwardInvocation:, which as far as I can tell would require some way to access parameter names.
You can use componentsSeparatedByString: with a : after you get the string from NSStringFromSelector(_cmd) and use your #selector's argument names to put the arguments in the correct order.
You can also take a look at this post, which is describing the method naming conventions in Objective C
How to add params to the MKNetworkOperation. When I use a NSDictionary it does not work because I would like to have something like this:
username=blabla&nr=1&nr=3&nr=4
nr is a list.
So I cannot treat nr as a key because it is not unique.
How can I solve this?
According the MKNetworkkit Multivalued parameters should be possible?
It is beyond me why you are not simply using NSURLConnection, so I can only guess what your third party framework is or is not capable of.
If I read the limitation you describe correctly, one solution that comes to mind is to just device your own scheme, e.g. like this:
username=blabla&nr=1,2,3,5,8,13,21
and then parse the number list yourself.
You can always construct the URL manually. If you pass nil in the 'params' argument of the operationWithPath:params:httpMethod:ssl:, the framework will leave the URL alone and not try and append anything at the end. You can start by using the NSDictionary+RequestEncoding.h methods to encode the initial url on an NSMutableString and then append the rest at the end.