Process Content-type properly in REST API when POSTing serialized data

[Alfiva]

There are two types of bodies to POST to REST API:

• When posting a space, publisher, callee, etc, the body format should be XML or JSON, and then inside it there would be a serialized Publisher, Callee, etc, which could be in Turtle or JSONLD.
• When posting Events or Requests however, the body format should be Turtle or JSONLD directly.

So...

1. First, a change would be required so that Turtle and JSONLD use the correct MIME types (text/turtle and applicaion/ld+json). Right now for instance it is using text/plain for Turtle.
2. Then, we should address the posting of events in batches, since the batch "format" is using XML or JSON as envelope, and it could interfere with the processing of other cases based on Content-type

[Alfiva]

In the meantime, if you want to post a single Event in JOSNLD format, a workaround is to envelop it in a multi-event batch, but containing only that Event.

[Alfiva]

I have created branch "issue/501" (see 087df27710f39359a2c4c7d4f74b98144447ab53) where I have a draft of the mentioned new behavior. Because this changes drasticallly how people have been using REST API (so far everyone used text/plain for Turtle bodies) it is better to keep it in a branch until we can announce it. I expect we could do this when we release 4.0.0 perhaps.

[buhideduardo]

i think the mime type need to be application/json instead of application/ld+json, because the mime refers to the body of request, not of the serialized format of the events. And i think too just we need 2 mime type availables: XML and Json The serializer is managed internaly and it not need to be related to the mime type of the request (we can send a multiple context event serialized in turtle events or in JsonLD...or some events in turtle and others in JsonLD). For example, posting to host:port/uaal/spaces/X/service/callees only the profile need to be deserialized, the rest of the body still a json object (not json ld)

[Alfiva]

As I said, there are 2 types of bodies:

• Spaces, Callers, Callees, Publishers, Subscribers: These bodies have to be application/xml or application/json, and some of them contain serialized Turtle/JSONLD content. That content is irrelevant for the MIME Content-type.
• ContextEvents, ServiceRequests, ServiceResponses: These bodies are sent as serialized Turtle/JSONLD straight away. Therefore they should be text/turtle or application/ld+json. Right now they are ingested as text/plain, which is incorrect anyway.

Then there is the special case of multiple Events in batches. The batch envelope is XML or JSON, while the contents are multiple Turtle or JSONLD. Therefore the right Content-type is like the first case: application/xml or application/json, irrespective of the serialized "subcontents" All these cases have been implemented this way in the mentioned branch.

[amedranogil]

In both cases of applicaiton/xml application/json (i.e. envelopes/non-messages and batch messages) I think we need to add a mime type property, not as header, but to distinguish the deserializer to use for each case.

The idea is that when sending a publisher (for example), the body is in fact in applicaiton/xml or application/json (specified in http header) provider info's mime type is initially unkown. So that the format of the body should include a property to tell the manager which deserializer to use.

The same applies to batch processing.

[Alfiva]

Yes, that would be the most "polite" way to do it. As it works now, it tries parsing the "subcontent" as Turtle first, then if it fails it tries JSONLD. Not clean, but it's how it's been working so far. There are several ways we could do it, like for instance using different fields depending on type ("providerinfoTurtle": vs "providerinfoJsonld":) or a dedicated field ("providerinfoType":"Turtle"). I guess it's up for debate, not as critical as the other issue.