Felix Meschberger wrote: * Extension (and optional selectors) have not derived from the URL yet
One of the lessons I think I see from how selectors & extensions are working in the face of creation requests to non-existent resources is that there should be a way to *override* what is derived from the existing resolution process. Consider that some URLs end up containing period characters which have nothing to do with a desire for a selector or extension, a prominent example is user ids. -Rob Ryan -----Original Message----- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Monday, April 07, 2014 12:25 AM To: dev@sling.apache.org Subject: Support REST-ful APIs Hi all TL;DR: Use Accept header to set request's selectors and extension. So an example Accept content type of "application/x-players+json" would set the selector string to "players" and the extension to "json". We always touted Sling to be a platform for REST-ful web applications. But we cheated a bit in that we "invented" request selectors and extensions for content negotiation instead of using the HTTP Accept header. The reason for this cheating was pure pragmatism since in Browsers the easy way to influence requests is basically just URLs and request parameters. Hence we built all request processing, prominently script/servlet selection on these selectors and extensions. And this proved highly effective. Still, trying to define "pure" REST-ful APIs we can assume applications to be able to set the HTTP Accept header and to be able to define clean URLs without selectors and extensions. So for a browser we want to support something like: > GET /teams/fcbasel.html HTTP/1.0 > Host: soccer.example.com while for REST-ful APIs more something like: > GET /teams/fcbasel HTTP/1.0 > Host: soccer.example.com > Accept: application/x-players+json What if Sling would convert the Accept content type "application/x-players+json" into > selectors = [ "players" ] > selectorString = "players" > extension = "json" This could be done in the Sling Engine's SlingRequestPathInfo constructor under the following conditions: * Extension (and optional selectors) have not derived from the URL yet * Accept header has a single content type (Browsers generally send a list of supported types) * Accept header is an application type * The sub type is converted to selector and extensions, where "+" is used as the separator WDYT ? Regards Felix
