My one-line contribution is a link to some REST docs that Nexus (a maven repository manager) has that we can maybe use as an example on the documentation side of things: https://docs.sonatype.com/display/NX/Nexus+Rest+API
-Eric On 05/19/2010 09:58 AM, Jennifer Bourey wrote:
I'm hopeful that we'll be able to start actively developing the target REST services once the Spring 3 update is complete. Some of the refactoring I've done in the last month was specifically designed to make our permissions systems more re-usable by portlets living outside of the uPortal webapp. I think it'll be great to start exposing clear APIs through REST, and I don't have any objection to people potentially developing new administrative tools for uPortal. That said, I'd like to remind everyone that we're currently in the middle of doing significant refactoring to essentially all of the portal's administrative portlets. If there are changes or additions you'd like to see in uPortal's administrative toolset, this would actually be a great time to discuss those use cases on-list. While it might be possible to develop external portlets to perform administrative tasks, I'd also like to ensure that uPortal ships with friendly, useful administrative portlets that meet the needs of most adopting institutions. It may turn out that we find reasons to develop some tools as external portlets, but I'd like to first try to fold any missing features into the default toolset. We've been actively soliciting input about our new administrative tools, so if you have suggestions, please let us know. If you're interested in plans for the next version of the permissions portlet, some documentation and wireframes is available at http://www.ja-sig.org/wiki/display/UPC/Permissions+Manager+Portlet. Beyond that, I'd suggest that we prioritize REST services for things that are genuinely useful and are good targets for modification outside of the portal. For example, it might not actually be a good idea to allow external portlets to do things like delete entity types. That seems unlikely to have a clear use case and would be particularly likely to cause errors in the portal. It might be helpful to talk about some real use cases in the community and discuss what operations would be useful in portlet development. From my perspective, the highest value REST service for portlet development will likely center around groups, users, and permissions. - Jen On May 19, 2010, at 10:41 AM, Eric Dalquist wrote:Thanks for the page. It would be great to move this discussion to the uportal-dev list. For a current efforts status update. JenB is working on rewriting the AJAX UI features for 3.3, part of that effort is creating a set of REST based APIs using Spring 3's REST annotation support. The end goal for these APIs is to have them published as a standard way for code external to uPortal to perform administrative tasks. The initial focus for functionality will be the calls needed for portlet manager, groups manager, permissions manager, end user layout management and fragment layout management. I'm not sure exactly what her status is on these but I know she is stuck a bit on the service implementation since we can't update trunk to Spring 3 until I get the Pluto 2 branched merged back in, which will hopefully be happening some time next week. Another note I'll make on the page, links to the Pluto Driver API docs aren't all that usefull, the driver is Pluto's demo portal and we won't actually be using any code from that or the driver-impl package in 3.3 final. -Eric On 05/19/2010 09:15 AM, Gary Weaver wrote:http://www.ja-sig.org/wiki/display/UPC/Proposal+for+Standardizing+Portal+Services I know that we don't have resources for it, but I thought I may as well follow through with a proposal based on Tim's interest in it. Not much, and may not help, but at least it is documented. --- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user
smime.p7s
Description: S/MIME Cryptographic Signature
