Más contenido relacionado


Rest and Sling Resolution

  1. REST & Sling Resolution DEEPAK KHETAWAT
  2. 1. What is Rest. 2. What is Sling and How Sling Uses Rest. 3. Sling Resolution Agenda
  3. ABOUT ME  AEM6 Certified Expert Consultant  LinkedIn : khetawat/96/a44/99a  Twitter : @dk452  For any query mail at
  4. -> 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
  5. -> 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
  6. 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
  7. 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
  8. 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
  9. -> 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
  10. -> Default behaviour for GET -> Creating/Updating content through POST – Default behaviour -> Additional operations/method -> Resource-first request processing! Rest with Apache Sling
  11. -> 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
  12. -> 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
  13. -> 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
  14. Resource First Request Processing
  15. 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
  16. 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
  17. URL Decomposition Example
  18. Analyzing the Following Url : http://myhost/tools/spy.printable.a4.html/a/b?x=12 URL Decomposition Example
  19. 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
  20. URL Decomposition Terminologies:
  21. From URL to Content and Scripts:
  22. 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).
  23. 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.
  24. 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).
  25. 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.
  26. 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.
  27. 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).
  28. 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.
  29. 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.
  30. 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
  31. 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
  32. 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.
  33. 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}
  34. 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('.', '/').
  35. 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.
  36. 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
  37. 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.
  38. 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.)
  39. 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
  40. 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.
  41. References : ml# jcr-osgi-scripting-and-rest g/the_basics.html
  42. Questions??:
  43. Thanks..