How can I get themedisplay object in XYZServiceImpl?
My scenarios is like I am trying to fetch all document using web services but I need to WebDAV URL for each document using which user can download document.
I have done some googling for the same and I found following methods which provides the webdav and thumbnail but for that I required themedisplay object.
1.) DLUtil.getWebDavURL(themeDisplay, folder, fileEntry);
2.) DLUtil.getThumbnailSrc(fileEntry, dlFileShortcut, themeDisplay)
Also I need to check permission for each folder and document to get permission checker object I need themedisplay object.
Can anyone help me to get out from this as soon as possible OR any alternate solution to get this object?
The only (maintainable) way to get themeDisplay in your API calls is by requiring it as a parameter to the interface. In general though, this is a bad habit, as themeDisplay contains a lot of stuff from the front end layer, and typically your services should be well decoupled from the front layer. In fact, they might be called from contexts where there is no themeDisplay, in pure API calls.
Thus, the methods that you point to are made to be used from places where ThemeDisplay is available, but I'd like them better if they just required the necessary details instead of requiring the whole lot of themeDisplay information. On the other hand, that would make 4 instead of 1 parameter
If you build a service, you shouldn't require a themeDisplay as parameter. This might be easier said than done - it'll be more work for you, but provide cleaner code. On the other hand, you might have to duplicate the method that I've linked to above. There is no "correct" way to solve the problem under these circumstances, you'll have to judge for yourself
Edit: Answering to your comment: You can't get themeDisplay in a call that's coming in through the API - it's just not there. Now if you really need it and there's no way around: Look at the actual implementation of the method that you're going to call (which I've conveniently linked above) and create & initialize a ThemeDisplay object with the data that is required by the method you're going to call. And always remember that this is a workaround, don't do this routinely
Related
I am using a Filter to detect some api operations and do some validation work. what is the normal way to get which api operation is currently called using HttpServletRequest? Right now, I am doing something like this :
if (httpRequest.getMethod().equalsIgnoreCase("GET")
&& httpRequest.getRequestURI().toLowerCase().contains("expectedOperatinName"))
to check if it is the expected api call. However,
it is not a smart way to do that to me
more importantly, how does it distinguish btw list and get a single
Please help. Thanks
Did you look into the UriInfo interface that has methods on which resource matched the passed in request? You can access the UriInfo from the request like this:
containerRequestContext.getUriInfo()
I think you can easily find out which operation was honored using getMatchedResources() on the UriInfo. If you are trying to find the exact method that honored the request, look into UriRoutingContext class.
I am creating a RESTful webservice and I have a URL like this:
GET /pets
For normal users this should only return the pets that belongs to that user. But for admin it should return all pets in the system. Is this wrong to do? Or should I instead do this
GET /pets?ownedBy=Smith
and only allow access to the pets if the user is either Smith or an admin?
I don't think REST specifications mentions anything about it specifically. But IMPO, I believe it is perfectly right to return the results as per the requesting user. URLs should be kept as cleaner as possible. If user information is already present as part of headers, then it is not required to provide it in URL redundantly.
While answer from Juned Ahsan is perfectly correct IMHO, I would probably modify your URLs pattern to something like
GET /Smith/pets : return pets for Mr Smith
Authorization can now be done one layer up in the URL and URLs always represent the same resource. I tend to prefer this solution because it will be easier to add a caching layer on top of it. Adding the user (from HTTP header) to the cache key is not efficient, nor is it easy to configure for some caching solution.
I would only provide it in the URL if you also have cases where it is valid to put someone else's name there. For example if people are able to see their friends pet or if and admin is able to see a selected person's pets.
So in the situation where you have a user for that parameter it would make sense to expose it and always use it.
If that is not the case though then simplicity in your API is generally a good thing.
To answer the "can" in your question as well as the "should" though - it's entirely possible. Exactly how to implement it would depend on the framework you are using but they will all support this.
These two URLs are different.
The first one gives a list of pets.
The second one gives also a list of pets, but in this case the list is filtered by the property "owner".There is nothing wrong with this. I would change the second URL slightly to:
GET /pets?owner=Smith
The key with that this URL is, that the type of the result is the same (a list of pet entities), and the meaning is the same too. There is only a filter applied to the list. That is where the query is made for in REST.
In some cases a Path parameter would be better. If you have entities "person", which do have a property of type list of pets, I would create a path like
/<user>/pets
If the list of pets are the root elements I would use a query.
I think it is up to the implementation in the back-end service. Currently, I am working in a similar fashion on a WCF RESTful service (although for Android). And if you have some roles that you can add in your database, it is not so difficult to apply that in your service, and your url would have nothing to do with that.
Edit: If you do want to have something in the URL, you can always add that. But I do not think that it is necessary at all. The less the users see, the better.
As mentioned earlier by Christian Kuetbach using REST you would pass parameters separated by /
i.e. /<userid>/pets if you have any other user specific functionality, or maybe other way around /pets/<userid>. I would suggest using UUID as userID - this way it will ensure user details security
I've used both Play1.x and Play2.x, but I didn't find how Play distributes its request to different actions in its source code.
e.g.
http://HOST:9000/Application/index
Play could find the controller Application, and then invoke its index method.
I thought Play works this way:
Get URI's first part Application and init Application using reflection.
Get the second part of URI, index, invoke index() of Application using reflection.
But I don't know where's the code exactly.
And, If it using a lot of reflection, how could it handle millions of request ? I think reflection is a lot of slower than direct method call(Or Play make some magic optimize ?).
Route file get compiled into target/scala-2.10/src_managed/main/routes_routing.scala file.
Even if reflection would be involved why should it be slow? File need to be reflected once at app startup.
The route file points each uri to a specific method.
For example:
GET /clients/:id controllers.Clients.show(id: Long)
If you don't care about routes type-safety incorporated in Play 2.x you can easily write custom resolver which will catch all unhandled routes with Dynamic parts spanning several / so using simple string operations + reflections you can access any controller/action combination you want...
Anyway consider if your app's security is worth of this sacrifice.
PS.: hard believing that samples are not required to this approach, in other case let me know, I'll write something in free time
This must have been answered previously, but my Google powers are off today and I have been struggling with this for a bit. We are migrating from an old PHP base to a Jersey-based JVM stack, which will ultimately provide a JSON-based RESTful API that can be consumed from many applications. Things have been really good so far and we love the easy POJO-to-JSON conversion. However, we are dealing with difficulties in Cross-Domain JSON requests. We essentially have all of our responses returning JSON (using #Produces("application/json") and the com.sun.jersey.api.json.POJOMappingFeature set to true) but for JSONP support we need to change our methods to return an instance of JSONWithPadding. This of course also requires us to add a #QueryParam("callback") parameter to each method, which will essentially duplicate our efforts, causing two methods to be needed to respond with the same data depending on whether or not there is a callback parameter in the request. Obviously, this is not what we want.
So we essentially have tried a couple different options. Being relatively new to Jersey, I am sure this problem has been solved. I read from a few places that I could write a request filter or I could extend the JSON Provider. My ideal solution is to have no impact on our data or logic layers and instead have some code that says "if there is a call back parameter, surround the JSON with the callback, otherwise just return the JSON". A solution was found here:
http://jersey.576304.n2.nabble.com/JsonP-without-using-JSONWithPadding-td7015082.html
However, that solution extends the Jackson JSON object, not the default JSON provider.
What are the best practices? If I am on the right track, what is class for the default JSON filter that I can extend? Is there any additional configuration needed? Am I completely off track?
If all your resource methods return JSONWithPadding object, then Jersey automatically figures out if it should return JSON (i.e. just the object wrapped by it) or the callback as well based on the requested media type - i.e. if the media type requested by the client is any of application/javascript, application/x-javascript, text/ecmascript, application/ecmascript or text/jscript, then Jersey returns the object wrapped by the callback. If the requested media type is application/json, Jersey returns the JSON object (i.e. does not wrap it with the callback). So, one way to make this work is to make your resource method produce all the above media types (including application/json), always return JSONWithPadding and let Jersey figure out what to do.
If this does not work for you, let us know why it does not cover your use case (at users at jersey.java.net). Anyway, in that case you can use ContainerRequest/ResponseFilters. In the request filter you can modify the request headers any way you want (e.g. adjust the accept header) to ensure it matches the right resource method. Then in the response filter you can wrap the response entity using the JSONWithPadding depending on whether the callback query param is available and adjust the content type header.
So what I ultimately ended up doing (before Martin's great response came in) was creating a Filter and a ResponseWrapper that intercepted the output. The basis for the code is at http://docs.oracle.com/cd/B31017_01/web.1013/b28959/filters.htm
Essentially, the filter checks to see if the callback parameter exists. If it does, it prepends the callback to the outputted JSON and appends the ) at the end. This works great for us in our testing, although it has not been hardened yet. While I would have loved for Jersey to be able to handle it automatically, I could not get it to work with jQuery correctly (probably something on my side, not a problem with Jersey). We have pre-existing jQuery calls and we are changing the URLs to look at the new Jersey Server and we really didn't want to go into each $.ajax call to change any headers or content types in the calls if we didn't have to.
Aside from the small issue, Jersey has been great to work with!
I am creating a web application that incorporates REST-style services and I wanted some clarification as to the preferred (standard) method of how the POST requests should be accepted by my Java server side:
Method 1:
http://localhost:8080/services/processser/uid/{uidvalue}/eid/{eidvalue}
Method 2:
http://localhost:8080/services/processuser
{uid:"",eid:""} - this would be sent as JSON in the post body
Both methods would use the "application/json" content-type, but are there advantages, disadvantages to each method. One disadvantage to method 2, I can immediately think of is that the JSON data, would need to be mapped to a Java Object, thus creating a Java object any time any user access the "processuser" servlet api. Your input is much appreciated.
In this particular instance, the data would be used to query the database, to return a json response back to the client.
I think we need to go back a little from your question. Your path segment starts with:
/services/processuser
This is a mistake. The URI should identify a resource, not an operation. This may not be always possible, but it's something you should strive for.
In this case, you seem to identify your user with a uid and an eid (whatever those are). You could build paths such as a user is referred to by /user/<uid>/<eid>, /user/<uid>-<eid> (if you must /user/uid/<uid>/eid/<eid>); if eid is a specialization, and not on equal footing with uid, then /user/<uid>;eid=<eid> would be more appropriate.
You would create new users by posting to /user/ or /user/<uid>/<eid> if you knew the identifiers in advance, deleting users by using DELETE on /user/<uid>/<eid> and change state by using PUT on /user/<uid>/<eid>.
So to answer your question, you should use PUT on /user/<uid>/<eid> if "processuser" aims to change the state of the user with data you provide. Otherwise, the mapping to the REST model is not so clean, possibly the best option would be to define a resource /user/process/<uid>/<eid> and POST there with all the data, but a POST to /user/process with all the data would be more or less the same, since we're already in RPC-like camp.
For POST requests, Method 2 is usually preferred, although often the resource name will be pluralized, so that you actually post to:
http://localhost:8080/services/processusers
This is for creating new records, however.
It looks like you're really using what most RESTful services would use a GET request for (retrieving a record), in which case, Method 1 is preferred.
Edit:
I realize I didn't source my answer, so consider the standards set by Rails. You may or may not agree that it is a valid standard.