Using the REST API

[Kris]

Hi all,

I've been using the REST API to glue the iTEC widget store interface
onto edukapp which is working well for the most part.
I have a couple of questions though.

Firstly, it would be useful to have date uploaded and date modified
associated with the widget object so when you call

/api/search

or

/api/featured

the results also have dates in the json data returned

associated with this it would be great to have order by date or order
by rating or order by most downloaded
for the search.

This would allow me to have
Latest
Most popular
Most downloaded
Featured

as navigation elements in the store interface

The next issue is with registration. Currently the registration
servlet has an autoforward to a jsp file.
It would be useful to have something more RESTFul. Does this create
issues with the shiro plugin?

I'm happy to have a go at some of these if everyone is okay with this?

Cheers

Kris

[Scott Wilson]

On 23 May 2012, at 10:15, Kris wrote:

> Hi all,

Hi Kris,

>
> I've been using the REST API to glue the iTEC widget store interface
> onto edukapp which is working well for the most part.
> I have a couple of questions though.
>
> Firstly, it would be useful to have date uploaded and date modified
> associated with the widget object so when you call
>
> /api/search
>
> or
>
> /api/featured
>
> the results also have dates in the json data returned
>
> associated with this it would be great to have order by date or order
> by rating or order by most downloaded
> for the search.
>
> This would allow me to have
> Latest
> Most popular
> Most downloaded
> Featured
>
> as navigation elements in the store interface

That sounds good to me. There are some stubs in WidgetProfileService for some of these queries already, they just need the comparators writing. If you'd like to tackle those that would be great.

>
> The next issue is with registration. Currently the registration
> servlet has an autoforward to a jsp file.
> It would be useful to have something more RESTFul. Does this create
> issues with the shiro plugin?

I don't think so - there should be an Ajax registration API not requiring a redirect as that also means we could make a nicer UI in the JSP too.

>
> I'm happy to have a go at some of these if everyone is okay with this?

Yes please!

>
> Cheers
>
> Kris

[Kris Popat]

A couple of quick questions

There are two search function stubs in WidgetProfileService that I'm not sure about

searchWidgetProfilesOrderedByPopularity

How should popularity be calculated, I've already implemented ...OrderedByRating using WidgetStats.averageRating

is popularity an amalgam of downloads and embeds or do I need to factor in ratings too?


secondly...

searchWidgetProfilesOrderedByRelevance

This seems to be pointing towards the weighting factor of the affordances idea, but this isn't implemented. I can implement this but it will mean messing with the data model a bit. Is this correct, or was there something else that ppl had in mind?

Kris

[Scott Wilson]

On 23 May 2012, at 16:38, Kris Popat wrote:

> A couple of quick questions
>
> There are two search function stubs in WidgetProfileService that I'm not sure about
>
> searchWidgetProfilesOrderedByPopularity
>
> How should popularity be calculated, I've already implemented ...OrderedByRating using WidgetStats.averageRating
>
> is popularity an amalgam of downloads and embeds or do I need to factor in ratings too?

I'd expect some combo of views, downloads and embeds.

>
> secondly...
>
> searchWidgetProfilesOrderedByRelevance
>
> This seems to be pointing towards the weighting factor of the affordances idea, but this isn't implemented. I can implement this but it will mean messing with the data model a bit. Is this correct, or was there something else that ppl had in mind?

This is the default returned from Solr - results are ranked according to relevance match to the query terms. If we want to factor in affordances, we'd have to push those into the Solr record as an additional indexed and weighted field used in search.

[Kris Popat]

On 24 May 2012, at 10:19, Scott Wilson wrote:

>
> On 23 May 2012, at 16:38, Kris Popat wrote:
>
>> A couple of quick questions
>>
>> There are two search function stubs in WidgetProfileService that I'm not sure about
>>
>> searchWidgetProfilesOrderedByPopularity
>>
>> How should popularity be calculated, I've already implemented ...OrderedByRating using WidgetStats.averageRating
>>
>> is popularity an amalgam of downloads and embeds or do I need to factor in ratings too?
>
> I'd expect some combo of views, downloads and embeds.

Okay, what I suggest is in order of importance
embeds - as ppl are actually using the widget
downloads - as ppl are trying it out
views - ppl were interested in the description or widget type

I just have to play around with weighting factors for each to do the comparison

how about
embeds 1:1
download 1:4
views 1:20

I'll make it so these factors can be changed in a config file.

>
>>
>> secondly...
>>
>> searchWidgetProfilesOrderedByRelevance
>>
>> This seems to be pointing towards the weighting factor of the affordances idea, but this isn't implemented. I can implement this but it will mean messing with the data model a bit. Is this correct, or was there something else that ppl had in mind?
>
> This is the default returned from Solr - results are ranked according to relevance match to the query terms. If we want to factor in affordances, we'd have to push those into the Solr record as an additional indexed and weighted field used in search.

Okay this is fine for now then

I have some ideas about affordances/unctionalities which might be best handled by a new database table - I'll experiment with this a little and maybe push to a branch so others can try out.

[Scott Wilson]

On 24 May 2012, at 11:14, Kris Popat wrote:

>
> On 24 May 2012, at 10:19, Scott Wilson wrote:
>
>>
>> On 23 May 2012, at 16:38, Kris Popat wrote:
>>
>>> A couple of quick questions
>>>
>>> There are two search function stubs in WidgetProfileService that I'm not sure about
>>>
>>> searchWidgetProfilesOrderedByPopularity
>>>
>>> How should popularity be calculated, I've already implemented ...OrderedByRating using WidgetStats.averageRating
>>>
>>> is popularity an amalgam of downloads and embeds or do I need to factor in ratings too?
>>
>> I'd expect some combo of views, downloads and embeds.
>
> Okay, what I suggest is in order of importance
> embeds - as ppl are actually using the widget
> downloads - as ppl are trying it out
> views - ppl were interested in the description or widget type
>
> I just have to play around with weighting factors for each to do the comparison
>
> how about
> embeds 1:1
> download 1:4
> views 1:20
>
> I'll make it so these factors can be changed in a config file.

OK - though bear in mind especially for scenarios like ITEC viewing and using the widget directly in the store (maximised) may be the major use rather than embedding.