Body not JSON-LD as requested

[Stuart Chalk]

Sorry for cross-posting...

When I send a simple command to create a new container in F4, if I request JSON-LD as the content type I get a string as the body, i.e.

object(HttpSocketResponse) {
	body => 'http://localhost:8080/fcrepo/rest/testy7'
	headers => array(
		'Server' => 'Apache-Coyote/1.1',
		'ETag' => '"6f6d7daaa9e80c7a6968dfe7367e19a1d443f085"',
		'Last-Modified' => 'Mon, 25 Jan 2016 10:15:33 GMT',
		'Location' => 'http://localhost:8080/fcrepo/rest/testy7',
		'Content-Type' => 'application/ld+json',
		'Content-Length' => '40',
		'Date' => 'Mon, 25 Jan 2016 10:15:33 GMT',
		'Connection' => 'close'
	)
	cookies => false
	httpVersion => 'HTTP/1.1'
	code => '201'
	reasonPhrase => 'Created'
	raw => 'HTTP/1.1 201 Created
Server: Apache-Coyote/1.1
ETag: "6f6d7daaa9e80c7a6968dfe7367e19a1d443f085"
Last-Modified: Mon, 25 Jan 2016 10:15:33 GMT
Location: http://localhost:8080/fcrepo/rest/testy7
Content-Type: application/ld+json
Content-Length: 40
Date: Mon, 25 Jan 2016 10:15:33 GMT
Connection: close

Is this a bug or is it designed this way?  I was expecting

body => '["http://localhost:8080/fcrepo/rest/testy7"]'

Stuart

[Daniel Lamb]

The response for that API call is always just the uri of the created resource.  I don’t think setting content type in the headers has much effect.  For uniformity across all other calls that create resources (like transactions), the location header is really what you’re looking for.

~Danny

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

[Stuart Chalk]

On Thursday, January 28, 2016 at 8:58:33 AM UTC-5, Daniel Lamb wrote:

The response for that API call is always just the uri of the created resource.  I don’t think setting content type in the headers has much effect.  For uniformity across all other calls that create resources (like transactions), the location header is really what you’re looking for.

~Danny

On Jan 28, 2016, at 9:35 AM, Stuart Chalk <stuart...@gmail.com> wrote:

 
Danny

Thanks for the fast reply.

Stuart

[Robert Sanderson]

So ...  it shouldn't respond that the body is Content-Type: application/ld+json when it's just a text/plain string.

That, at least, seems like a bug to me.

Also ... can I inquire about the rationale for including the URL as the body, when it's already there in the Location header?  LDP requires the header, and makes no requirements for the body, so it's not a bug, but it seems like there are some optimizations that could be made.  For example, if the response contained a representation of the data that is actually created with the new triples, it would save a round trip to retrieve it?

Rob

--

You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Benjamin Armintor]

I agree with Rob that if the response content-type is application/ld+json, it is a bug for a non-empty entity to be anything but valid json-ld. It needs to either set the correct content-type, format the response correctly, or send no entity back. Is there a ticket?

- Ben

[Trey Terrell]

+1. I fuzzily remember Justin requesting that a year or so ago when implementing ActiveFedora, don't remember where the ticket is.

Trey

[Esmé Cowles]

Rob-

Agree that it's a bug that it's returning a string but setting Content-Type to something else.

And I also agree it would be nice to return the representation. One issue is that the spec says that clients cannot depend on that representation (see 5.2.3.1 https://www.w3.org/TR/ldp/#ldpc-HTTP_POST). It doesn't, strictly speaking, say we can't return it, though. Avoiding another hit to fetch it does seem like a good optimization, though it seems like it would encourage a slightly-incompatible behavior.

-Esmé

[Trey Terrell]

All that means is client libraries shouldn't count on the body being useful, but if it's there it can use it, yeah?

[A. Soroka]

Returning a representation would impact performance by the time to build that representation, which in the case of many resources, will mean going to persistence and calculating triples. Perhaps this could be an adjustable behavior… for some cases the client may have no immediate interest in the representation and no desire to wait for it.

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

We have a mechanism for this in line with the LDP spec: Prefer: return=representation. But that's a feature ticket, the other part is a bug.

[Robert Sanderson]

Adam,

That's a great point!  If the client is just trying to fire and forget the request in some sort of batch upload process, it would dramatically slow things down for no reason.

Could the current behavior be retained with an Accept header of text/plain (and the default if there's no Accept header for compatibility), and then also allow other content negotiation for the representation of the created resource?

Rob

[Daniel Lamb]

That definitely sounds like the best of both worlds.

[Benjamin Armintor]

If we retain a Accept-appropriate response entity including only the minted URI, should that:

1. Be our interpretation of Prefer: return=minimal

2. Be a response to Prefer: return=representation with a TBD include URI

How broad is the audience that only wants the URI but can't parse or set headers?

- Ben

[A. Soroka]

I’m be inclined to dispense with it: that is, either a proper representation or an empty body.

---
A. Soroka
The University of Virginia Library

[Esmé Cowles]

Ben-

+1 to returning the created URI as a string being Prefer: return=minimal

I think the only use case for returning the URI in the body is for convenience when using curl on the command line -- since it's much easier to deal with that then parsing the headers. If you were using basically any other client, then getting the Location header would probably be easier than getting it from the body.

-Esmé

> On Jan 28, 2016, at 11:03 AM, Benjamin Armintor <armi...@gmail.com> wrote:
>

[Robert Sanderson]

For those not familiar with Prefer: return=minimal

From RFC 7240:

The "return=minimal" preference, on the other hand, indicates that the client wishes the server to return only a minimal response to a successful request. [...] The determination of what constitutes an appropriate minimal response is solely at the discretion of the server. [...] In contrast, the "return=minimal" preference can reduce the amount of data the server is required to return to the client following a request.

https://tools.ietf.org/html/rfc7240#page-9

This seems like a good option, and would avoid overloading the Content Type.

I could imagine:

Request:

    POST /path/to/container/

    Prefer: return=minimal

    Accept: application/ld+json

    Content-Type: text/turtle

    <> a eg:Test .

Response:

    Content-Type: application/ld+json

    {"@id": "newly-minted-uri"}

Rob

[Benjamin Armintor]

I've created two tickets from this thread:

https://jira.duraspace.org/browse/FCREPO-1878 [On creation of LDPR, Content-Type is inappropriate to response entity]

https://jira.duraspace.org/browse/FCREPO-1879 [Prefer header should determine response entity on LDPR creation]

The latter is a feature request, feedback welcome.