REST & Sling Resolution
DEEPAK KHETAWAT

1. What is Rest.
2. What is Sling and How Sling Uses Rest.
3. Sling Resolution
Agenda

ABOUT ME
 AEM6 Certified Expert Consultant
 LinkedIn :
https://www.linkedin.com/pub/deepak-
khetawat/96/a44/99a
 Twitter : @dk452
 For any query mail at
deepakkhe.90@gmail.com

-> Note that REST is actually used with two meanings, subtly different from
each other. This can be confusing.
-> The pure meaning is the architectural style -- which is completely
independent of HTTP and the Web. It can be used with HTTP and the Web, but
it doesn't have to be.
-> The real-world meaning, most commonly used in the industry, is how REST
is used in practice: HTTP-based, and with standard Web servers (e.g., Apache
httpd) playing the part of REST servers.
-> Unless stated otherwise, the rest of this tutorial refers to the "real-world"
usage of REST.
What is Rest

-> REST stands for Representational State Transfer. It relies on a stateless,
client-server, cacheable communications protocol -- and in virtually all cases,
the HTTP protocol is used.
-> In many ways, the World Wide Web itself, based on HTTP, can be viewed as
a REST-based architecture.
-> RESTful applications use HTTP requests to post data (create and/or update),
read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all
four CRUD (Create/Read/Update/Delete) operations.
What is Rest

The REST architectural style describes six constraints
1. The uniform interface constraint defines the interface between clients and
servers. It simplifies and decouples the architecture, which enables each
part to evolve independently. The four guiding principles of the uniform
interface are:
a)Resource-Based
b)Manipulation of Resources Through Representations
c)Hypermedia as the Engine of Application State (HATEOAS)
d)Self-descriptive Messages
2. Stateless : Essentially, what this means is that the necessary state to handle
the request is contained within the request itself, whether as part of the URI,
query-string parameters, body, or headers. The URI uniquely identifies the
resource and the body contains the state (or state change) of that resource.
Then after the server does it's processing, the appropriate state, or the piece(s)
of state that matter, are communicated back to the client via headers, status
and response body.
What is Rest

3. Cacheable : As on the World Wide Web, clients can cache responses.
Responses must therefore, implicitly or explicitly, define themselves as
cacheable, or not, to prevent clients reusing stale or inappropriate data in
response to further requests. Well-managed caching partially or completely
eliminates some client–server interactions, further improving scalability and
performance.
4. Client-Server: The uniform interface separates clients from servers. This
separation of concerns means that, for example, clients are not concerned
with data storage, which remains internal to each server, so that the
portability of client code is improved. Servers are not concerned with the
user interface or user state, so that servers can be simpler and more
scalable. Servers and clients may also be replaced and developed
independently, as long as the interface is not altered.
What is Rest

5. Layered System: A client cannot ordinarily tell whether it is connected
directly to the end server, or to an intermediary along the way. Intermediary
servers may improve system scalability by enabling load-balancing and by
providing shared caches. Layers may also enforce security policies.
6. Code on Demand (optional): Servers are able to temporarily extend or
customize the functionality of a client by transferring logic to it that it can
execute. Examples of this may include compiled components such as Java
applets and client-side scripts such as JavaScript.
Complying with these constraints, and thus conforming to the REST
architectural style, will enable any kind of distributed hypermedia system to
have desirable emergent properties, such as performance, scalability,
simplicity, modifiability, visibility, portability and reliability.
What is Rest

-> It is a web application framework based on REST principles that provides
easy development of content-oriented applications.
-> Sling uses a JCR repository, such as Apache Jackrabbit, or Day's CRX, as
its data store.
Sling is content-centric : This means that processing is focused on the content
as each (HTTP) request is mapped onto content in the form of a JCR resource
(a repository node):
The first target is the resource (JCR node) holding the content.
Secondly, the representation, or script, is located from the resource properties
in combination with certain parts of the request (e.g. selectors and/or the
extension).
-> Everything is a resource.
-> Extending from JCR's Everything is Content, Sling assumes Everthing is a
Resource. Thus Sling is maintaining a virtual tree of resources, which is a
merger of the actual contents in the JCR Repository and resources provided by
so called resource providers. By doing this Sling fits very well in the paradigma
of the REST architecture.
What is Sling and How Sling Uses Rest

-> Default behaviour for GET
-> Creating/Updating content through POST
– Default behaviour
-> Additional operations/method
-> Resource-first request processing!
Rest with Apache Sling

-> Sling's abstraction of the thing addressed by
the request URI
– Usually mapped to a JCR node
– File system, database...
-> Properties of resources
– Path, e.g. JCR Item path
– Type, e.g. JCR node type
– Metadata, e.g. last modification date
Resource

-> Decompose the URL
-> Search for a file indicated by the URL
-> Resolve the resource (using the path from the URL)
-> Resolve rendering script/servlet
Don‘t call scripts directly in Sling!
Primary source: Resource Type
-> Create rendering chain
Configurable (Servlet) filters
Rendering Servlet
-> Invoke rendering chain
Basic Request Processing Steps

-> Gateway for resources
-> Abstracts the path resolution
-> Abstracts access to the persistence layer(s)
-> Configurable
– Mappings (Multi-site mgmt, beautify paths)
-> Tasks:
– Finding Resources
– Getting Resources
– Simplification of Query Execution
Resource Resolver

Resource First Request Processing

Resource Path
:The substring of the request URL before the first dot (.)
: Might be the complete URL if there‘s no dot
Example: /some/path.s1.s2.html
Selectors
:Substring between the first dot and the dot leading the extension
:Used for alternative methods of rendering the content
:Multiple selectors possible
:Optional
Example: /some/path.s1.s2.html
URL Decomposition

Extension
: The string between the last dot after the resource path and the
next slash
: Specifies the content format
: Optional
Example: /some/path.s1.s2.html
Suffix Path
: Path starting with the slash up to the end of the request URL
: At least a dot must be in the URL to let Sling detect the suffix path
: Can be used to provide additional information for the
processing script
Example: /some/path.s1.s2.html/suffix.html
URL Decomposition

URL Decomposition Example

Analyzing the Following Url :
http://myhost/tools/spy.printable.a4.html/a/b?x=12
URL Decomposition Example

From URL to Content and Scripts :
Using these principles:
->The mapping uses the content path extracted from the request
to locate the resource when the appropriate resource is located,
the sling resource type is extracted, and used to locate the script
to be used for rendering the content .
->The figure in next slide illustrates the mechanism used, which
will be discussed in more detail in the following sections

URL Decomposition Terminologies:

From URL to Content and Scripts:

Mapping Requests to Resources:
-> The request is broken down and the necessary information extracted.
The repository is searched for the requested resource (content node):
-> First Sling checks whether a node exists at the location specified in the
request; e.g. ../content/corporate/jobs/developer.html
-> If no node is found, the extension is dropped and the search repeated;
e.g. ../content/corporate/jobs/developer
-> If no node is found then Sling will return the http code 404 (Not Found).

Locating the Script:
-> When the appropriate resource (content node) is located, the sling resource type
is extracted. This is a path, which locates the script to be used for rendering the
content.
The path specified by the sling:resourceType can be either:
Absolute or
Relative, to a configuration parameter
-> Relative paths are recommended by Adobe as they increase portability.
-> All Sling scripts are stored in subfolders of either /apps or /libs, which will be
searched in this order.

Locating the Script..
-> When the Method (GET, POST) is required, it will be specified in uppercase
as according to the HTTP specification e.g. jobs.POST.esp
-> various script engines are supported:
.esp, .ecma: ECMAScript (JavaScript) Pages (server-side execution)
.jsp: Java Server Pages (server-side execution)
.java: Java Servlet Compiler (server-side execution)
.jst: JavaScript templates (client-side execution)
-> The list of script engines supported by the given instance of CQ are listed
on the Felix Management Console
(http://localhost:4502/system/console/config/slingscripting.txt).

Locating the Script..
-> Using the above example, if the sling:resourceType is hr/jobs then for:
-> GET/HEAD requests, and URLs ending in .html (default request types, default
format)
The script will be /apps/hr/jobs/jobs.esp; the last section of the sling:resourceType
forms the file name.
-> POST requests (all request types excluding GET/HEAD, the method name must be
uppercase)
POST will be used in the script name.
The script will be /apps/hr/jobs/jobs.POST.esp.
-> URLs in other formats, not ending with .html
For example ../content/corporate/jobs/developer.pdf
The script will be /apps/hr/jobs/jobs.pdf.esp; the suffix is added to the script name.

Locating the Script..
URLs with selectors
-> Selectors can be used to display the same content in an alternative format.
-> For example a printer friendly version, an rss feed or a summary.
-> If we look at a printer friendly version where the selector could be print; as in
../content/corporate/jobs/developer.print.html
The script will be /apps/hr/jobs/jobs.print.esp; the selector is added to the script name.

Locating the Script..
-> If no sling:resourceType has been defined then: the content path will be used to
search for an appropriate script (if the path based ResourceTypeProvider is active).
-> For example, the script for ../content/corporate/jobs/developer.html would generate a
search in /apps/content/corporate/jobs/.
the primary node type will be used.
-> If no script is found at all then the default script will be used.
-> The default rendition is currently supported as plain text (.txt), HTML (.html) and
JSON (.json), all of which will list the node's properties (suitably formatted). The default
rendition for the extension .res, or requests without a request extension, is to spool the
resource (where possible).

Locating the Script..
-> If multiple scripts apply for a given request, the script with the best match is
selected. The more specific a match is, the better it is; in other words, the more
selector matches the better, regardless of any request extension or method name
match.

Finding by Resource Super Type :
-> In addition to the resource types (primarily defined by the
sling:resourceType property) there is also the resource super type.
This is generally indicated by the sling:resourceSuperType property.
-> These super types are also considered when trying to find a script.
-> The advantage of resource super types is that they may form a
hierarchy of resources where the default resource type
sling/servlet/default (used by the default servlets) is effectively the
root.
->The resource super type of a resource may be defined in two
ways:
by the sling:resourceSuperType property of the resource.
by the sling:resourceSuperType property of the node to which the
sling:resourceType points.

Finding by Resource Super Type ..
For example:
/
a
b
sling:resourceSuperType = a
c
sling:resourceSuperType = b
x
sling:resourceType = c
y
sling:resourceType = c
sling:resourceSuperType = a
The type hierarchy of /x is [ c, b, a, <default>] while for /y the hierarchy is [
c, a, <default>] because /y has the sling:resourceSuperType property
whereas /x does not and therefore its supertype is taken from its resource
type

Sling Scripts cannot be Called directly :
-> Within Sling, scripts cannot be called directly as this would break
the strict concept of a REST server; you would mix resources and
representations.
-> If you call the representation (the script) directly you hide the
resource inside your script, so the framework (Sling) no longer knows
about it. Thus you lose certain features:
->Automatic handling of http methods other than GET, including:
POST, PUT, DELETE which are handled with a sling default
implementation
the POST.jsp script in your sling:resourceType location
->Your code architecture is no longer as clean nor as clearly
structured as it should be; of prime importance for large-scale
development

Revision for Sling Mapping Urls’s to Script
-> All requests are NOT equal.
->GET and HEAD request methods are treated differently than the other
request methods.
->Only for GET and HEAD requests will the request selectors and
extension be considered for script selection. For other requests the servlet
or script name (without the script extension) must exactly match the
request method.
->That is for a PUT request, the script must be PUT.esp or PUT.jsp. For a
GET request with a request extension of html, the script name may be
html.esp or GET.esp.

Scripts For Get Requests:
-> Apart for supporting scripts named after the request method, scripts handling GET
and HEAD requests may be named differently for Sling to support a more elaborate
processing order.
-> Depending on whether request selectors are considered, a script may have two
forms:
a. Ignoring request selectors (e.g. there are none in the request URI)
{resourceTypeLabel}.{requestExtension}.{scriptExtension}

Scripts For Get Requests..
b. Handling request selectors {selectorStringPath}.{requestExtension}.{scriptExtension}
The constituents of these script names are as follows:
{resourceTypeLabel} - The last path segment of the path created from the resource
type. This part is optional if the {requestExtension} is used in the script name.
{requestExtension} - The request extension. This part may be ommitted if the request
extension is "html", otherwise this part is required. If this part is ommitted, the
{resourceTypeLabel} is required in the case of ignoring the selectors.
{scriptExtension} - The extension, e.g. "esp" or "jsp", identifying the scripting langauage
used.
{selectorStringPath} - The selector string converted to a path, along the lines of
selectorString.replace('.', '/').

Rules for Script Path Priotization:
-> The more request selectors are matched, the better .
-> A script including the request extension matches better than one without a request
extension (for html only) .
-> A script found earlier matches better than a script found later in the processing order.
This means, that script closer to the original resource type in the resource type
hierarchy is considered earlier.

Example 1:
Taking up again the list of potential script paths for a request of a resource whose
resource type is sling:sample and the request selectors are "print.a4" and the request
extension is "html" could be:
(0) GET.esp
(1) sample.esp
(2) html.esp
(3) print.esp
(4) print/a4.esp
(5) print.html.esp
(6) print/a4.html.esp

Examples..
The priority of script selection would (6) - (4) - (5) - (3) - (2) - (1) - (0). Note that (4) is a
better match than (5) because it matches more selectors even though (5) has an
extension match where (4) does not.

Concept of Folder/Hierarchy Based
Resolution..
-> The more request selectors are matched, the better.
-> Note that a script with more than one selector doesn't get selected i.e, if you have a
script x.y.jsp, where x and y are your selectors, it is ignored by sling.
-> But it would still select the script y.jsp, present inside a folder x i.e., If the request is
for test.x.y.html, then
-basepage
_x |
_y.jsp (selected) |
_x.y.jsp (ignored) |
_x.jsp (selected in case x/y.jsp is not present. The script containing the first selector is
chosen in such cases.)

Example 2.
-> How Sling will Call the Script on the basis of url.
-> Have a page /content/AEMProject/English/test.html which has resourceType
AEMProject/components/page/basepage
-> Resouce basepage has 4 script files :
1. basepage.html.jsp
2. basepage.jsp
3. html.jsp
4. GET.jsp

Examples..
Script resolution order in previous example is 1 > 3 > 2 > 4
-> html.jsp would always take preference over your component.jsp, not the other way
round.
-> GET.jsp should execute in the worst case scenario, i.e., when none of the other files
are present, unless you have inherited this from some other component.

References :
http://www.restapitutorial.com/lessons/whatisrest.ht
ml#
http://www.slideshare.net/cziegeler/apache-sling-
jcr-osgi-scripting-and-rest
http://docs.adobe.com/docs/en/cq/current/developin
g/the_basics.html
http://rest.elkstein.org/2008/02/what-is-rest.html

Questions??:

Thanks..