This will be a great enhancement to the uPortal REST API, nice write up James! There may be some merit in having it be more abstract like the canonical filter (eg /p/fname). UW's use case for that is in our favorites list we only allow 1 per fname, granted once it is in the layout we do have the node id. However, another use case is when someone launches the portlet directly without having it in there layout.
I totally agree the 302 should never happen to the home. Maybe just a 400 level error with a "object doesn't exist therefore it is not" message or something. Thanks, Tim Levett tim.lev...@wisc.edu MyUW-Infrastructure ________________________________ From: bounce-41491308-70367...@lists.wisc.edu <bounce-41491308-70367...@lists.wisc.edu> on behalf of James Wennmacher <jwennmac...@unicon.net> Sent: Thursday, May 28, 2015 4:15 PM To: uportal-dev@lists.ja-sig.org Subject: [uportal-dev] uPortal API endpoint for returning portlet markup (aka exclusive window_state alternative) for Rich JS UI and uMobile For the Rich-JS Angular uPortal front-end we are working on, we need to create a uPortal API for returning portlet markup without using the current EXCLUSIVE window-state strategy. As Anthony elaborated in http://jasig.275507.n4.nabble.com/Name-for-new-window-state-that-was-like-DETACHED-td4665156.html, this (mis)use of Window State has some negative ramifications. We are finding much the same. I am planning on following Andrew P's excellent idea (also in the above thread) of creating a uPortal REST endpoint that returns the markup for a single portlet, effectively like EXCLUSIVE mode without actually setting or using the Window State. I want to discuss and collaborate on this feature as I see it having broad applicability, minimally the two rich JS UIs and uMobile. I haven't dug into the code details yet so I'm sure I'll find a few things that might require some changes, but I wanted to present my overall thoughts first for community feedback: * endpoint is /uPortal/api/portlet/{fname}.{ID}/exclusive * As opposed to /uPortal/api/portlet/{fname} which returns minor portlet publishing info * Including ID which would be from /uPortal/layout.json or /uPortal/api/layout/v2/layout.json after https://issues.jasig.org/browse/UP-4438 is processed. Including ID since a portlet can appear multiple times on a page so fname is not sufficient. * Must return the markup as response body. Failure to return markup should return appropriate HTTP error code. Should never return a 302. I propose: * 200 - content returned in response body * 204 - no content (I think it is better the portal definitively indicates no content). An example of this might be when a portlet is minimized or has no content? * 302 - A poorly formed URL that goes into uPortal would do the normal 302 to a uPortal landing page, but I consider this a client-side error we probably shouldn't try to prevent. * 304 - return this if supporting eTag (or If-Modified-Since but I'm not sure this makes sense)? * 401 - Unauthorized (need to authenticate) * 403 - Forbidden for some reason, probably that it exists but user doesn't have access to it * 404 - for invalid portlet ID or URL (assuming URL at least gets to the endpoint) * 500 - for portlet throwing an error, etc. * markup returned in body of response. If portlet supports RENDER_HEADERS, perhaps this should be the combined RENDER_HEADERS plus content (RENDER_HEADERS content first of course). Questions: * Should the HTTP Cache headers respect the portlet cache parameters; e.g. if portlet's entry in portlet.xml had <expiration-cache>60</expiration-cache> should the HTTP cache headers indicate a 60 second cache time? I think not since an Action request should invalidate the cache. The JS UI could figure that out, but the browser could not. If we always send an eTag and maybe If-Modified-Since on the response and allow uPortal to intelligently manage the caching primarily using its existing render output cache mechanism, I think this would be as good as we need. * Do we need to allow for ?refresh=true to force invoking the portlet and not using cached render output? I don't know of a use case for this at this point. Potential future expansions: * Create an endpoint to return content for a list of portlets or all portlets on a specific tab I welcome your thoughts on this idea. Written up as https://issues.jasig.org/browse/UP-4478. -- James Wennmacher - Unicon 480.558.2420 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
