What are the different ways to retrieve a node in adobe cq5 and out of those which has to prefer.
I knows three method only one is through session , request and another one is through resourceResolver.
Here are those..
Node rootNode = session.getNode(path);
by request
Node currentNode = request.getResource().adaptTo(Node.class);
by resourceResolver
String resourcePath = "path/to/resource";
Node.node = resourceResolver.getResource(resourcePath).adaptTo(Node.class);
Out of these which one one is best way to retrieve and why ?
First it is discouraged to ask question like this, as it triggers oppinion based answers. Nonetheless I try to be as objecitve as I can. I think it depends on the use case, e.g. where in your code do you want to get the node:
If you already are in a servlet,
request.getResource().adaptTo(Node.class) is probably the most
straightforward way.
If you already have a jcr Session, it is easiest to use the
getNode(path) method
If you already have a ResourceResolver getResource(path) or resolve(path) are fine as well.
Me personally prefer the Sling API over the JCR, so I usually work with Resources anyway thus I mostly use the ResourceResolver or its Adapters: PageManager, TagManager, etc.
I even think internally it all ends up with session.getNode(path) as the ResourceResolver relies on a Session (you can adapt it to it) and request.getResource() probably uses the resolve(path) method.
There is no "best way". If you already have a NODE object then if you are trying to get say... all the children then there is listChildren(). Really the best way is a use case.
The real question is why you want a NODE specifically. Unless you are creating data in the JCR, there is usually no need for the node interface. 99% of the time the system handles node creation for you, so you are reading data, in which case resource.adaptTo(ValueMap.class) is probably your best bet.
If you add more details about WHY you are concerned about this and the context, I can help you further.
Related
It is straightforward to put resource id into url if it is a int or long type. e.g.
GET files/123
But my problem is that my resource identifier is a path. e.g. /folder_1/folder_2/a.sh because the underlying implementation is a filesystem. So I can not put it as part of rest api url because it is conflict with url path.
Here's approaches what I can think of:
Put the path id as the request param. e.g.
GET files?path=/folder_1/folder_2/a.sh
Encode/decode the path to make it qualifier as part of url.
Introduce another int/long id for this resource in backend. And map it to the path. The int/long type resource id is stored in database. And I need to maintain the mapping for each CURD operation.
I am not sure whether approach 1 is restful, approach 2 needs extra encoding/decoding, and approach 3 needs extra work to maintain the mapping.
I wonder what is the best practice to design the rest api url for this kind of case.
Simple:
#GET
#Path("/files/{path:.+}")
#Produces({MediaType.TEXT_PLAIN})
public String files(
#PathParam("path") String path
) {
return path;
}
When you query files/test1/tes2 via url output is:
test1/tes2
Just put the path after a prefix, for example:
GET /files/folder_1/folder_2/a.sh
There isn't a conflict, since when the request path starts with your known prefix (/files/, in the above example), you know that the rest should be parsed as the path to the file, including any slashes.
Well, my experience designing "restful" APIs shows that you have to take into consideration future extensions of your API.
So, the guidelines work best when followed closely when it makes sense.
In your specific example, the path of the file is more of an attribute of the file, that can also serve as its unique ID.
From your API client's perspective, /files/123 would make perfect sense, but /files/dir1/file2.txt is debatable.
A query parameter here would probably help more, much like what you would do if you wanted to retrieve a filtered list of files, rather than the whole collection.
On the other hand, using a query parameter would also help for future extensions, since supporting /files/{path} would also mean conflicts when attempting to add sub-resources to your files endpoint.
For example, let's assume that you might need in the future another endpoint /files/attributes. But, having such an endpoint, would exclude any possibility for your clients to match a file named attributes.
Assume you have a REST service that already gets users by id, so the url looks something like
GET /users/{userId}
But you want to create a duplicate web service that gets users by email, so:
GET /users/{email}
Which is better?
Method 1:
Same method:
/users/{input}
...
if(isEmail(input)) queryByEmail(input);
else queryById(input);
Method 2:
Different Method:
GET /users/{userId}
GET /usersByEmail/{email}
Since there is no actual overlap between email addresses and IDs. I would just use same endpoint for both. Especially if GET /users/{id} is already a published interface.
So, I would go with 1st method.
GET /users/{identifier}
Then on the API server you have to add a small check, whether {identifier} is a number or not.
I would also like to note, that "pretty URLs" do not make it REST :) You probably will want to watch this lecture: https://www.youtube.com/watch?v=pspy1H6A3FM
My personal preference would be,
GET /users/id/{id}
GET /users/email/{email}
But it all depends on what you the rest endpoints to look like.
Which is better?
REST doesn't care; from the perspective of the client, the URI is opaque. The clients concerns are following links/submitting forms/completing templates.
Information encoded into the URI is done at the server's discretion and for its own exclusive use.
So you can use any spelling you like. As a rule, it's a good idea to conform to local spelling conventions (in much the same way that your variable names in code should conform to your coding conventions). But your clients shouldn't need to know the details of those conventions.
/users/{input}
...
if(isEmail(input)) queryByEmail(input);
else queryById(input);
Note that you aren't necessarily deeply committed to one approach; that's part of the point of decoupling the identifiers from the representations. For instance, your implementation could just as easily look like
/users/{input}
...
if(isEmail(input)) redirectTo(/users/email/{input});
else redirectTo(/users/id/{input});
which allows clients that have bookmarked the original URI to arrive at the correct resource.
What's the correct "RESTful" URL for an action that adds a child record to a parent record?
For example, if I wanted to provide a URL for adding a "comment" record to an "order" record, how should I format it?
My first thought was something like:
PUT http://example.com/order/12345/comment/add
I work in Django, which uses a similar pattern, so this seemed most intuitive. However, reading over some RESTful design guides like this one suggests that this might be bad practice, as they argue the "PUT" and "add" are redundant and therefore might create confusion.
I would do the following:
POST http://example.com/order/12345/comment
The put action and the add part of the url are redundant. But there is no hard rule on any of this. I see apis having that form, even from major vendors, and sometimes simply remark "The put action and the uri segment are redundant" Sometimes I say nothing at all and just call the endpoint. If I were writing an api, I would probably leave off the add part.
there are few points to make your request RESTful:
1) Use resources names in the URL in plural and not in a singular form (orders instead of order)
2) never use ACTION names in your URL such as (ADD) in "comment/add"
3) since you are adding a "NEW" comment without knowing any IDs of hands you should use POST request.
Finally, the URL I would recommend is:
HttpVerbs = POST
http://api.example.com/orders/12345/comments
That should add a new comment to your order#12345
There is no one-size-fits-all answer to your question. Rest URLs can be whatever you want them to be. At the end of the day, they are routes that get mapped to a method. I wouldn't worry too much about the "best" URL. I prefer to find a standard that works for me and then move on to bigger, more important things. As long as clients know what the URL is, they will be fine.
I'm wondering where to put the edit, and new keywords by rest application. I'll use express-resource in a project, and the default settings are these:
GET /forums -> index
GET /forums/new -> new
POST /forums -> create
GET /forums/:forum -> show
GET /forums/:forum/edit -> edit
PUT /forums/:forum -> update
DELETE /forums/:forum -> destroy
There is a problem with this solution: there is not a real resource behind the new and edit. I mean the URL-s refer to resources, and after any slash is a sub-resource.
For example:http://my.example.com/users/1 represents:
var firstUser = {
name: "John Smith",
birthDate: new Date(1952,10,4),
hobbies: ["skiing", "football"],
...
}
And http://my.example.com/users/1/birthDate represents:
firstUser.birthDate
But by http://my.example.com/users/1/edit there is no such property:
firstUser.edit
So something is wrong with this conception.
Where is the real place of these keywords? In queryString or in headers?
From the perspective of a REST API these do not exist anywhere as they are not related to the representation of resources. They are actions upon resources and therefore expressed by the HTTP methods used. They would not bee needed if you were to create an external client that uses the API.
There is likely a need to provide some support for this type of functionality so that something like a UI could be presented, but that is the concern of the particular application and not the API itself. At that point it becomes discretionary but I would certainly avoid using headers as that would be pretty outside of conventional practice. But by headers it appears that you actually meant URI path. Out of those 2 I would say the path is the better option since it clearly defines any type of UI as a distinct resource and would keep it apart from the clean API, while using a query string on a part of the API would more tightly (mistakenly) associate it with the underlying resource.
Some update after a year or so:
edit and new should be hyperlinks
these links are just the representations of possible operation calls
by following them it is possible to manipulate the resource they belong by sending representations of the intended resource state, and/or by calling the proper methods
these terms are no resources, they don't have their own URL (resource identifier)
Thanks the advices Matt Whipple!
I think the best way to learn REST is reading the Fielding dissertation. There are many tutorials out there, but the authors of most of these does not really understand REST.
I'm sorry in advance if this rather n00bish question actually has an answer in the documentation which I've just failed to find, but
I'm still relatively new to GWT, and try as I might I can't find an explanation of what the request.with(String...) method actually does which I can understand. Please can someone explain to me in words of one sylable what this method does and why you'd use it?
thanks very much
It indeed is in the doc: https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory#relationships
By default, entity proxies referenced from the entity proxy/ies you're fetching are not fetched (properties will simply be null on the client-side). You have to explicitly ask for them using with(), passing the name (can be a dotted path too) of the properties you want to fetch.