Andy, we've been through this already:
http://mail-archives.eu.apache.org/mod_mbox/jena-users/201202.mbox/%3ccae35vmzpcczxswt37etsb_5bzw6qgv-uufphy8bx6ssh4u9...@mail.gmail.com%3E
OK, maybe I should say JAX-RS and Jersey as its implementation, which
also includes the client.
JAX-RS allows not only high-level annotations, but also low-level
conneg if there is a need for it, both on server and client sides.
Here's an example of actual code I have at hand:
ResultSet resultSet = getResultSet();
EntityTag entityTag = new
EntityTag(Long.toHexString(ResultSetUtils.hashResultSet(resultSet)));
Response.ResponseBuilder rb =
getRequest().evaluatePreconditions(entityTag);
if (rb != null)
{
if (log.isTraceEnabled()) log.trace("Resource not modified,
skipping
Response generation");
return rb.build();
}
else
{
Variant variant =
getRequest().selectVariant(RESULT_SET_VARIANTS);
if (variant == null)
{
if (log.isTraceEnabled()) log.trace("Requested Variant {}
is not
on the list of acceptable Response Variants: {}", variant,
getVariants());
return Response.notAcceptable(RESULT_SET_VARIANTS).build();
}
else
{
if (log.isTraceEnabled()) log.trace("Generating SPARQL
results
Response with Variant: {} and EntityTag: {}", variant, entityTag);
return Response.ok(resultSet,
variant).tag(entityTag).build();
// uses ResultSetWriter
}
}
Jena has different HTTP code scattered all over the place, while
JAX-RS/Jersey covers all HTTP use cases (that I came across) within
Linked Data -- what else do we need?
Martynas
On Thu, Dec 6, 2012 at 10:36 PM, Rob Vesse <[email protected]> wrote:
> On 12/6/12 12:31 PM, "Andy Seaborne" <[email protected]> wrote:
>
>
>>On 06/12/12 20:03, Martynas Jusevičius wrote:
>>> If Jena would be consistent in its HTTP handling and use an
>>> established API such as JAX-RS, things could be much easier.
>>
>>Could you explain that a bit more so we can see what can be improved (or
>>submit a patch)? Do you have specific suggestions?
>>
>>JAX-RS is an API for mapping Java with annotations to web resources.
>>
>>HTTP is a protocol.
>
> I agree, I don't see how JAX-RS is relevant here.
>
> However perhaps we should be ensuring that everywhere that does anything
> HTTP uses the Apache HttpClient as a point of standardization and provide
> ways to better expose that up to users to add custom configuration?
>
> As Andy says patches are welcome in this area. I know I've done some work
> in the past to improve configurability on the remote query side but it
> still uses the java.net APIs rather than HttpClient as the remote update
> stuff does.
>
>>
>>The question is about the use of content negotiation on SPARQL update
>>requests i.e. the bits on the wire. Surely the client API or server
>>implementation should work with any legal bits on the wire (and be
>>defensive about illegal bits?)
>
> +Many
>
> Though we should consider Postel's law here - "Be liberal in what you
> accept and conservative in what you send"
>
> In this particular case we are complying with this and Dydra is not as I
> see it.
>
> Rob
>
>>
>> Andy
>>
>>
>>
>>>
>>> Martynas
>>> graphity.org
>>>
>>> On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <[email protected]> wrote:
>>>> My two cents:
>>>>
>>>> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
>>>> proved to be a pretty awful implementation of HTTP conneg and SPARQL
>>>> protocols in general compared to other similar systems like Sesame,
>>>> Stardog, Fuseki etc. and I had to put an awful lot of implementation
>>>> specific hacks in place to get things working.
>>>>
>>>> For example I have a still open bug related to something very similar
>>>>to
>>>> this
>>>>
>>>>(https://getsatisfaction.com/dydra/topics/basic_digest_http_authenticati
>>>>on_
>>>> is_not_supported) which relates to them doing dumb stuff with conneg
>>>>and
>>>> not just using HTTP authentication nicely. In essence if you are not
>>>> logged in and the Accept header does not ask for machine readable
>>>>formats
>>>> they automatically redirect to a HTML login form instead of doing HTTP
>>>> auth. This is particularly problematic because their processing of the
>>>> Accept header is poor, if you so much as mention HTML in there it will
>>>> think you are a browser even if machine readable formats are ahead of
>>>>HTML
>>>> in the Accept header.
>>>>
>>>> I agree with Andy that maybe there is some room for improvement in
>>>>Jena to
>>>> allow this to be configured in general but I wouldn't want to turn
>>>>this on
>>>> in general just to work with Dydra which I'm still expecting to die a
>>>> death. I know for a fact that one of their core developers has long
>>>>since
>>>> parted ways with the company and I haven't seen any activity on any of
>>>>my
>>>> various open bugs in a long time.
>>>>
>>>> Rob
>>>>
>>>>
>>>> On 12/6/12 3:14 AM, "Andy Seaborne" <[email protected]> wrote:
>>>>
>>>>> Hi Simon,
>>>>>
>>>>> What a nuisance. It's not, as far as I know, illegal, but it is a
>>>>> rather odd interpretation of HTTP POST for remote operations.
>>>>>
>>>>> Not sending "Accept" is because it's a POST which does not need to
>>>>> return anything. conneg for an HTML page is find but it's not conneg
>>>>>if
>>>>> it returns it without being asked for! I'm a bit worried that
>>>>>changing
>>>>> in the general casefor Dydra means it will be inconvenient elsewhere.
>>>>> (And don't some (old) browsers send */* always?)
>>>>>
>>>>> So it's will need some sort of configuration mechanism to make it
>>>>> endpoint specific.
>>>>>
>>>>> Good news - every UpdateProcessor has a Context object that is
>>>>> associated with the request. It's currently null for a remote request
>>>>> but the mechanism is at least there.
>>>>>
>>>>> Remote query (either QueryExecutionFactory.sparelService or SERVICE
>>>>>in a
>>>>> query) has a mechanism for setting the request with custom headers.
>>>>>
>>>>> See ARQ.serviceParams and class Service.
>>>>>
>>>>> Do you want to raise a JIRA for this? And (ideally) contribute a
>>>>>patch?
>>>>>
>>>>> Andy
>>>>>
>>>>> On 05/12/12 21:43, Simon Gábor wrote:
>>>>>> Hi Andy,
>>>>>>
>>>>>> I am trying to use Dydra (http://dydra.com/). It requires to send
>>>>>>Accept
>>>>>> header, otherwise it returns with a full HTML webpage (with Dydra's
>>>>>> online
>>>>>> query tool on it). For update commands it is happy with just an
>>>>>>Accept:
>>>>>> */*
>>>>>> then returns 200 and a simple boolean SPARQL XML result.
>>>>>>
>>>>>> Example:
>>>>>> POST http://dydra.com/orkszoft/test01/sparql HTTP/1.1
>>>>>> Accept: */*
>>>>>> Content-Length: 364
>>>>>> Content-Type: application/sparql-update
>>>>>> Host: dydra.com
>>>>>> Connection: Keep-Alive
>>>>>> User-Agent: Apache-HttpClient/4.2.2 (java 1.5)
>>>>>> Authorization: Basic ***
>>>>>>
>>>>>> PREFIX dc: <http://purl.org/dc/elements/1.1/>
>>>>>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>>>>> PREFIX owl: <http://www.w3.org/2002/07/owl#>
>>>>>> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>>>>>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>>>>>
>>>>>> DELETE DATA {
>>>>>> <http://dbpedia.org/resource/San_Francisco> rdfs:label "My San
>>>>>> Francisco"
>>>>>> .
>>>>>> }
>>>>>>
>>>>>> Response:
>>>>>> HTTP/1.1 200 OK
>>>>>> Content-Type: */*
>>>>>> Connection: keep-alive
>>>>>> Status: 200
>>>>>> X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.9
>>>>>> Cache-Control: no-cache
>>>>>> X-UA-Compatible: IE=Edge,chrome=1
>>>>>> Set-Cookie: _dydra_session=****; path=/; HttpOnly
>>>>>> X-Runtime: 0.849964
>>>>>> Server: nginx/1.0.8 + Phusion Passenger 3.0.9 (mod_rails/mod_rack)
>>>>>> Access-Control-Allow-Origin: *
>>>>>> Access-Control-Allow-Credentials: *
>>>>>> Content-Length: 123
>>>>>>
>>>>>> <?xml version='1.0'?>
>>>>>> <sparql xmlns='http://www.w3.org/2005/sparql-results#'>
>>>>>> <head/>
>>>>>> <boolean>true</boolean>
>>>>>> </sparql>
>>>>>>
>>>>>>
>>>>>> I'm having trouble to decide whether Dydra has a faulty design (it's
>>>>>>not
>>>>>> conform with the protocol recommendation) or Jena has no support for
>>>>>>the
>>>>>> optional content negotiation (or both)?
>>>>>> It's for sure that Dydra's method is somewhat weird because for a
>>>>>>wrong
>>>>>> SPARQL it returns code 400 - so it seems that the response body
>>>>>>holds no
>>>>>> new info.
>>>>>>
>>>>>>
>>>>>> Gabor Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/12/5 Andy Seaborne <[email protected]>
>>>>>>
>>>>>>> On 03/12/12 12:44, Simon Gábor wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> According to the SPARQL Update protocol recommendation:
>>>>>>>> "The response body of a successful update request is implementation
>>>>>>>> defined. Implementations *may* use HTTP content negotiation to
>>>>>>>>provide
>>>>>>>> both
>>>>>>>>
>>>>>>>> human-readable and machine-processable information about the
>>>>>>>>completed
>>>>>>>> update request."
>>>>>>>>
>>>>>>>> How can i specify accept header in the SPARQL Update request? I
>>>>>>>>cannot
>>>>>>>> find
>>>>>>>> a way in UpdateProcessor (UpdateProcessRemote) or in UpdateRequest.
>>>>>>>>
>>>>>>>
>>>>>>> Simon,
>>>>>>>
>>>>>>> There currently isn't a way to do that and also the .execute()
>>>>>>> operation
>>>>>>> does not return anything. Errors appear as exceptions driven from
>>>>>>>the
>>>>>>> HTTP
>>>>>>> response code.
>>>>>>>
>>>>>>> What had you in mind?
>>>>>>>
>>>>>>> I don't know of any systems currently that return different entity
>>>>>>> bodies
>>>>>>> based on conneg. Are there any?
>>>>>>>
>>>>>>> The reason in the spec for "MAY" is that there is no standard format
>>>>>>> for a
>>>>>>> reply. RDFa, RDF, JSON [1] (why have an RDF processor when you send
>>>>>>>a
>>>>>>> string?) all make sense in different scenarios.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>http://tools.ietf.org/html/**draft-nottingham-http-problem-**01<http:
>>>>>>>//t
>>>>>>> ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
