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..