[oslc-core] Creating multiple resources in one POST?

[Arthur Ryman]

John/Andy,

I am not a fan of multi-create since I don't see what's wrong with the 
client just doing multiple POSTs.

However, if OSLC wants to support multi-create, then perhaps the way to do 
this is using the multi-part MIME type. The request would contain one part 
for each creation request, the response would contain corresponding parts 
for the results.

Another route to multi-create might be SPARQL Update.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
John Arwe <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
10/06/2011 12:59 AM
Subject:
Re: [oslc-core] Creating multiple resources in one POST?
Sent by:
oslc-core-bounces at open-services.net



> Can this [batched creates] be considered as part of OSLC core? 
"In theory", anything could be.  I think the pragmatic issues have to do 
with consensus.  The idea of posting to a collection when you want the 
create semantic is not something OSLC invented at all.  It was in fairly 
widespread use in the wild already; AtomPub is the most commonly cited 
"original spec source" for the pattern, but I suspect lots of people would 
recognize it as factory create.  OSLC Core "just" took that pretty well 
accepted Best Practice, applied it to RDF data, and *wrote down* the 
result -- the latter being a gap that is being recognized in the Semantic 
Web community generally.  Some invention along the way was necessary 
(RDF/JSON) since the larger community had not prioritized that. 
In practice, I think it's a harder row to hoe with batched-anything. There 
is a much higher proportion of "invent new" relative to the case above, 
and no existing community consensus I'm aware of to "just write down". 
Implementations are headlights for spec work, have to be careful not to 
over-drive them. 

> And then it really helps the users to be able to create multiple 
resources with a single POST. 
This seems like it forgets about the error handling case you already 
acknowledged.  Life is [relatively, still have to solve Location] easy 
when it all works.  It's the partial error handling where it becomes 
difficult to achieve consensus - if you require ACID behavior, that's a 
fairly stringent server implementation requirement.  If you don't, 
well-behaved clients may have a lot of work to do. 
Don't get me wrong, batched requests generally show up in many of the 
scenarios I'm expecting to see flowing soon from Tivoli; updates + 
creates.  Maybe that eventually leads to a pattern people agree on.  It 
simply does not appear to be imminent based on the actual scenarios coming 
in so far. 
Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net