Re: Public SPARQL endpoints:managing (mis)-use and communicating limits to users.

On 4/18/13 4:53 PM, Rob Warren wrote:
> On 18-Apr-13, at 8:53 AM, Jerven Bolleman wrote:
>>
>> Many of the current public SPARQL endpoints limit all their users to 
>> queries of limited CPU time.
>> But this is not enough to really manage (mis) use of an endpoint. 
>> Also the SPARQL api being http based
>> suffers from the problem that we first send the status code and may 
>> only find out later that we can't
>> answer the query after all. Leading to a 200 not OK problem :(
>
> Jerven,
>
> I agree that a 200 reply to  'query too complex', 'query too big' or 
> 'query timeout' is not acceptable. However, limits on queries are a 
> tool to keep dumb clients from pounding on the server too hard.
>
> A standardized reply / error would be something that I would like to 
> see in that it allows the client to modify its approach to querying 
> the server. It would also be an opportunity to have the server signal 
> to the client what trade-off it is willing to make between sending 
> more triples and increasing the query complexity.
>
> Could '413 Request Entity Too Large', '429 Too Many Requests' and '453 
> Not Enough Bandwidth' be abused here for Sparql endpoints?
>
> rhw
>
>
>
>
>
Yep! That's the kind of enhancement that required i.e., use as many 
existing HTTP status codes as possible.


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen