Proposed webservice extension to expose search facet information

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposed webservice extension to expose search facet information

Justin Clark-Casey-2
There's a request to expose search facets information via webservice at [1], in the first instance to aid the ios intermine user interface.

I think there are 2 ways to go about this, (1) add the info to an existing endpoint (possibly branding/ which arguably already has precedent for this kind of
thing, or (2) create a new endpoint (possibly search/config) just to serve search config information.

A bit more detailed writeup at [2].  When I started thinking about this I was inclined to propose adding the info to branding/ but now leaning slightly towards
creating a new endpoint.  Comments welcome.

[1] https://github.com/intermine/intermine/issues/1632
[2] https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws

--
Justin Clark-Casey
http://twitter.com/justincc

_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed webservice extension to expose search facet information

Yo Yehudi-2
tbh, I would expect this info to be under an endpoint like GET /search/facets or something similar, which most closely matches your option 1. 

Putting it under branding doesn't make a lot of sense to me. It's not branding! Also, you reference the defaults as a precedent - most of those properties didn't make sense being under branding either and will be retired. Julie blogged about branding last week: https://intermineorg.wordpress.com/2017/07/12/mine-update-needed/ 

On 18 July 2017 at 17:11, Justin Clark-Casey <[hidden email]> wrote:
There's a request to expose search facets information via webservice at [1], in the first instance to aid the ios intermine user interface.

I think there are 2 ways to go about this, (1) add the info to an existing endpoint (possibly branding/ which arguably already has precedent for this kind of thing, or (2) create a new endpoint (possibly search/config) just to serve search config information.

A bit more detailed writeup at [2].  When I started thinking about this I was inclined to propose adding the info to branding/ but now leaning slightly towards creating a new endpoint.  Comments welcome.

[1] https://github.com/intermine/intermine/issues/1632
[2] https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws

--
Justin Clark-Casey
http://twitter.com/justincc

_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed webservice extension to expose search facet information

Daniela Butano-2

Option 1 sounds good to me. In general I prefer endpoints returning specific info instead of endpoint for general config (Option 2)

Daniela


On 19/07/17 10:00, Yo Yehudi wrote:
tbh, I would expect this info to be under an endpoint like GET /search/facets or something similar, which most closely matches your option 1. 

Putting it under branding doesn't make a lot of sense to me. It's not branding! Also, you reference the defaults as a precedent - most of those properties didn't make sense being under branding either and will be retired. Julie blogged about branding last week: https://intermineorg.wordpress.com/2017/07/12/mine-update-needed/ 

On 18 July 2017 at 17:11, Justin Clark-Casey <[hidden email]> wrote:
There's a request to expose search facets information via webservice at [1], in the first instance to aid the ios intermine user interface.

I think there are 2 ways to go about this, (1) add the info to an existing endpoint (possibly branding/ which arguably already has precedent for this kind of thing, or (2) create a new endpoint (possibly search/config) just to serve search config information.

A bit more detailed writeup at [2].  When I started thinking about this I was inclined to propose adding the info to branding/ but now leaning slightly towards creating a new endpoint.  Comments welcome.

[1] https://github.com/intermine/intermine/issues/1632
[2] https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws

--
Justin Clark-Casey
http://twitter.com/justincc

_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev



_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed webservice extension to expose search facet information

Daniela Butano-2

for clarity, i was referring to Options1 defined in the wiki page, not in the email :)


On 19/07/17 11:08, Daniela Butano wrote:

Option 1 sounds good to me. In general I prefer endpoints returning specific info instead of endpoint for general config (Option 2)

Daniela


On 19/07/17 10:00, Yo Yehudi wrote:
tbh, I would expect this info to be under an endpoint like GET /search/facets or something similar, which most closely matches your option 1. 

Putting it under branding doesn't make a lot of sense to me. It's not branding! Also, you reference the defaults as a precedent - most of those properties didn't make sense being under branding either and will be retired. Julie blogged about branding last week: https://intermineorg.wordpress.com/2017/07/12/mine-update-needed/ 

On 18 July 2017 at 17:11, Justin Clark-Casey <[hidden email]> wrote:
There's a request to expose search facets information via webservice at [1], in the first instance to aid the ios intermine user interface.

I think there are 2 ways to go about this, (1) add the info to an existing endpoint (possibly branding/ which arguably already has precedent for this kind of thing, or (2) create a new endpoint (possibly search/config) just to serve search config information.

A bit more detailed writeup at [2].  When I started thinking about this I was inclined to propose adding the info to branding/ but now leaning slightly towards creating a new endpoint.  Comments welcome.

[1] https://github.com/intermine/intermine/issues/1632
[2] https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws

--
Justin Clark-Casey
http://twitter.com/justincc

_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev



_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev



_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed webservice extension to expose search facet information

Justin Clark-Casey-2
Okay.  Personally, I think it may be better to place such information under a new general info/ endpoint to avoid proliferation of such endpoints in the future
and ensure consistency (e.g. so that plugin authors who want to expose such information don't take different approaches to structuring the json).  However, I
don't have a strong enough preference to argue the case and things can always be changed (at more effort) in the future, so I'll probably go with a search
specific endpoint.  Thanks for the feedback!

On 19/07/17 11:15, Daniela Butano wrote:

> for clarity, i was referring to Options1 defined in the wiki page, not in the email :)
>
>
> On 19/07/17 11:08, Daniela Butano wrote:
>>
>> Option 1 sounds good to me. In general I prefer endpoints returning specific info instead of endpoint for general config (Option 2)
>>
>> Daniela
>>
>>
>> On 19/07/17 10:00, Yo Yehudi wrote:
>>> tbh, I would expect this info to be under an endpoint like GET /search/facets or something similar, which most closely matches your option 1.
>>>
>>> Putting it under branding doesn't make a lot of sense to me. It's not branding! Also, you reference the defaults as a precedent - most of those properties
>>> didn't make sense being under branding either and will be retired. Julie blogged about branding last week:
>>> https://intermineorg.wordpress.com/2017/07/12/mine-update-needed/
>>>
>>> On 18 July 2017 at 17:11, Justin Clark-Casey <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>     There's a request to expose search facets information via webservice at [1], in the first instance to aid the ios intermine user interface.
>>>
>>>     I think there are 2 ways to go about this, (1) add the info to an existing endpoint (possibly branding/ which arguably already has precedent for this
>>>     kind of thing, or (2) create a new endpoint (possibly search/config) just to serve search config information.
>>>
>>>     A bit more detailed writeup at [2].  When I started thinking about this I was inclined to propose adding the info to branding/ but now leaning slightly
>>>     towards creating a new endpoint.  Comments welcome.
>>>
>>>     [1] https://github.com/intermine/intermine/issues/1632 <https://github.com/intermine/intermine/issues/1632>
>>>     [2] https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws <https://github.com/justinccdev/intermine/wiki/expose-search-facets-via-ws>
>>>
>>>     --
>>>     Justin Clark-Casey
>>>     http://twitter.com/justincc
>>>
>>>     _______________________________________________
>>>     dev mailing list
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.intermine.org/mailman/listinfo/dev <https://lists.intermine.org/mailman/listinfo/dev>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> [hidden email]
>>> https://lists.intermine.org/mailman/listinfo/dev
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> [hidden email]
>> https://lists.intermine.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> [hidden email]
> https://lists.intermine.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Loading...