I m new RIA services. I have to make two service call to validate two conditions and I m trying to use out param to know outcome of the validation function say output -1 will denote first validation failed, output -2 will denote second validation failed and if 0 everything is in order. How to include output/reference parameter in RIA service method.
AFAIK, you can not add out/ref parameters in RIA sevice methods, which are actually WCF methods.
instead, you can create a class that includes a property for validation outcome along with other properties, then return that class from the method.
Related
I am just new to rest api and need to create two api. both of them use post.
1) First one takes 2 parameters inside of the body
url is : /myapp/resources
2) Second one is doing the same function as the first one does but it needs 2 optional parameter. I thought using path or request param but as the parameters are optional it will be confusing when there is no paramaters. So there will be conflict with the first api.
/myapp/resources?param1=xx¶m2=xx ==> what if there is no parameter
/myapp/resources/param1/{xxx}/param2/{yyy} ==> so still what if there is no param:
So what is the best way to define second api without causing a conflict with the first api when optional parameters are not passed.
I would suggest going with the first approach (query params) so:
/myapp/resources?param1=xx¶m2=xx
The reason being - in this case you can define or extend the logic of just one endpoint, the /myapp/resources, that is going to verify if parameters exist and react accordingly.
With the second approach (path params), you would have to most likely define two (or more) separate endpoints (like /myapp/resources/, /myapp/resources/param1/{param1} and /myapp/resources/param1/{param1}/param2/{param2}
I have many crud operation.
User must be able to search by many field of the resource.
Some have around 10.
I could use RequestParam, but method will have a lot of parameter an habitually it's not a good pratice.
/card?id=2&imso=trx&icco=98x&type=23&scm=988&createat=2017-02-01
Is there another good solution?
There are two issues here and depending on what carries what importance to you - you can approach a solution.
Problem # 1 : Long REST URLs at client
Problem # 2 : Controller methods with long & complicated signatures
Solution 1 : You group your #RequestParam into optional & mandatory parameters and then you create a DTO only for optional parameters. Then You can have your controller method signature like controllerMethod(#RequestParam param1 , #RequestParam param2, DTO dto).
Note that, you don't use #RequestBody before DTO.
Values for DTO will be passed in client URL itself like before and Spring MVC automatically converts it into DTO.
This solves complicated controller method signature but not long URL problem while you retain your request type to be GET
It is assumed that usually mandatory parameters are only a few and there is always a long list of optional fields.
Solution 2: You change server side to convert your GET request to a POST and start accepting a #RequestBody DTO. This solves both the problems but your original API changes to POST type.
As far as I know, changing a GET to POST shouldn't be a problem in most cases but vice versa is not true.
I have configured my EF context configured like so
b.RegisterAssemblyTypes(webAssembly, coreAssembly)
.Where(t => t.IsAssignableTo<DbContext>())
.InstancePerLifetimeScope();
I would like to use it from a custom authorization attribute that hits the database using my EF context. This means no constructor-injection. I achieve this by using CommonSeviceLocator
var csl = new AutofacServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => csl);
...
var user = await ServiceLocator.Current
.GetInstance<SiteContext>().FindAsync(id);
I am finding that this fails with a "multiple connections not supported" error if the browser issues two simultaneous requests to routes using this attribute. It seems like this might be due to what is mentioned in this answer. My guess is that ServiceLocator resolves from the root scope rather than the web request scope and the two request are conflicting (either request in isolation works fine).
This seems confirmed by that when I change to InstancePerRequest() I get this from any invocation of the attribute.
Autofac.Core.DependencyResolutionException No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This generally indicates that a component registered as per-HTTP request is
being requested by a SingleInstance() component (or a similar scenario.) Under the web integration always request dependencies from the DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
So it seems like maybe ServiceLocator is simply not the way to go.
How do I resolve the request-scoped SiteContext from inside the attribute (using a service-locator pattern)?
Your issue derives from the fact that you are trying to put behavior inside of an Attribute. Attributes are for defining meta-data on code elements and assemblies, not for behavior.
Microsoft's marketing of Action Filter Attributes has led people implementing DI down the wrong path by putting both the Filter and the Attribute into the same class. As described in the post passive attributes, the solution is to break apart filter attributes into 2 classes:
An attribute that contains no behavior to mark code elements with meta-data.
A globally-registered filter that scans for the attribute and executes the desired behavior if present.
See the following for more examples:
Constructor Dependency Injection WebApi Attributes
Unity Inject dependencies into MVC filter class with parameters
Implementing passive attributes with dependencies that should be resolved by a DI container
Dependency Injection in Attributes: don’t do it!
Injecting dependencies into ASP.NET MVC 3 action filters. What's wrong with this approach?
How can I test for the presence of an Action Filter with constructor arguments?
Another option is to use IFilterProvider to resolve the filters as in IFilterProvider and separation of concerns.
Once you get your head around the fact that Attributes should not be doing anything themselves, using them with DI is rather straightforward.
I'm having two rest methods as follows
/objects/(int:type)/(id:objectID)/(ver:version)
/objects/(int:type)/(id:objectID)/(str:version)
if i send the request as like the following URI
http://localhost/REST/objects/0/123/latest which of the above method gets called.
whether the 2 methods are same or different.
need to know what are all the parameter types available and what is the actual usage of each type.
And how the URI identifies the exact method
That question is all about the server framework you are using and nothing about REST. REST says nothing about URI structure, and certainly nothing about how URIs are mapped to handlers.
I have a Java client that calls a RESTEasy (JAX-RS) Java server. It is possible that some of my users may have a newer version of the client than the server.
That client may call a resource on the server that contains query parameters that the server does not know about. Is it possible to detect this on the server side and return an error?
I understand that if the client calls a URL that has not been implemented yet on the server, the client will get a 404 error, but what happens if the client passes in a query parameter that is not implemented (e.g.: ?sort_by=last_name)?
Is it possible to detect this on the server side and return an error?
Yes, you can do it. I think the easiest way is to use #Context UriInfo. You can obtain all query parameters by calling getQueryParameters() method. So you know if there are any unknown parameters and you can return error.
but what happens if the client passes in a query parameter that is not implemented
If you implement no special support of handling "unknown" parameters, the resource will be called and the parameter will be silently ignored.
Personally I think that it's better to ignore the unknown parameters. If you just ignore them, it may help to make the API backward compatible.
You should definitely check out the JAX-RS filters (org.apache.cxf.jaxrs.ext.RequestHandler) to intercept, validate, manipulate request, e.g. for security or validatng query parameters.
If you declared all your parameters using annotations you can parse the web.xml file for the resource class names (see possible regex below) and use the full qualified class names to access the declared annotations for methods (like javax.ws.rs.GET) and method parameters (like javax.ws.rs.QueryParam) to scan all available web service resources - this way you don't have to manually add all resource classes to your filter.
Store this information in static variables so you just have to parse this stuff the first time you hit your filter.
In your filter you can access the org.apache.cxf.message.Message for the incoming request. The query string is easy to access - if you also want to validate form parameters and multipart names, you have to reas the message content and write it back to the message (this gets a bit nasty since you have to deal with multipart boundaries etc).
To 'index' the resources I just take the HTTP method and append the path (which is then used as key to access the declared parameters.
You can use the ServletContext to read the web.xml file. For extracting the resource classes this regex might be helpful
String webxml = readInputStreamAsString(context.getResourceAsStream("WEB-INF/web.xml"));
Pattern serviceClassesPattern = Pattern.compile("<param-name>jaxrs.serviceClasses</param-name>.*?<param-value>(.*?)</param-value>", Pattern.DOTALL | Pattern.MULTILINE);