Those all look very good to me!
support wrote:"I'll also standardize the other API entry points to use the same object/verb syntax. Maintaining backwards compatibility, of course. And document the whole lot."
Now that sounds like a lot of work. If you want to leave the existing API entry points as they are I think everybody would understand.
Here's some thoughts on some of the individual HTTP APIs:
I think I've mentioned this before... there are 4 output options that can be specified when a channel report is run, 1) it can be displayed in Awasu, 2) it can be emailed, 3) it can be saved to a file, and 4) it can be FTP'd. If this API is called from a remote machine, should the display of the report in Awasu be suppressed (provided that the user has specified that the specific report should be displayed in Awasu
)? Also would this API just return an HTTP Status Code to the caller: 200=success, 500=error.
Wow this is a lot more than was initially asking for, but if you can provide all this that's great!
From my Awasu Application Plugin perspective I was just thinking that I could pass some search terms to this API and it would open a new tab with the search results using the current search options. But I think in our emails we also discussed that if this API is called from a remote machine that it'd be nice to have a page of HTML search results passed back to the user. If you can provide XML and JSON output formats that would be really cool. There is a spec out there on the OpenSearch web site specifying response elements for RSS 2.0 and ATOM 1.0 OpenSearch response elements
, there's probably nothing like this in a JSON format although FWIW there is the OpenSearch JSON Search Suggestions Request/Response format
(I know Wikipedia uses this
So forget about opening a new tab with search results, pass back the XML/HTM/JSON and we'll open a new window or display it in a <iframe> or whatever is appropriate for our application.
If there are any Awasu users (non-programmers
) out there, this is a significant development for you too. We can create a Bookmarklet for you, that you can easily install in your web browser that can search your Awasu feed items for any text that you've selected in the current web page. That may not sound too exciting for you if you're sitting on the same PC where Awasu is running, but if you're on an intranet and you discover some terminology that's related to one of your fields of interest and you're wondering "I wonder if these terms appear in my Awasu feed items"; you can just select the terms click your bookmarklets and receive and answer from the Awasu server right away.
When we discussed this via email I suggested that you just provide an OPML list via an HTTP API, and I've done some work on transforming an OPML file into a couple of HTML formats using XSLT, I'll have provide an update to you via email so you can "see" what I'm talking about. The only problem with exposing the existing OPML format via an API is that it doesn't contain those special Awasu Channel (Search Channels and Plugin Channels
). If you can "extend" OPML with extra attributes, then maybe OPML could be the output format for this API.
But, whether this returns OPML or another format, I'll keep working on my OPML transformation code and I'll try to port it over to this output format too.
While this would be cool for easily building a report of a complex Awasu configuration. One of my email suggestions (not really a request just a thought "off the top of my head"
) was a slight modification to the "Add to Default Workpad" API where you specify a specific Workpad via its name or ID so this would be an "Add to Any Workpad" API.
A user could set up Bookmarklets for several of their favorite Workpads and send the URL/Titles of the current web page to the appropriate Workpad.
Now you've already carved out a big chunk of work for yourself and I don't really know how useful this would be given that Awasu version 2.4 can automatically send new items to any Workpads, so unless a bunch of other user's reply with "yes we need a Add to Any Workpad API", I think you can skip this one. But I did think I should bring this thought out into the open in the forum and let other people think about it.
This would be cool to get a list of all Channel Reports. It would be really easy in almost any programming language to call this API and build a web page of hyperlinks to call the /reports/run API. You could have a Channel Reports "remote control" page on an intranet site and secure it so that only Awasu administrators could access it. With the /reports/list API this code would not have to be updated as Channel Reports are added or deleted; it would always be the most current list.
All of this is sounds like a lot of work and I know you have other areas you want to work on, so if you have to scale this back a little bit, I think everybody will understand.