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

[Andrew J Berner]

Arthur Ryman said:  I am not a fan of multi-create since I don't see what's
wrong with the
client just doing multiple POSTs.   (then, and I appreciate this, continued
to explain how it might be done).

Let me explain why I suggested this, when it's obvious that the "client"
could just do multiple POSTs.   And while potentially an issue, it's not
the performance of the network traffic I'm concerned about...

One of the advantages of the use of HTTP based technology for the api is
that a lot can be done through a browser, especially with plugins that
allow you to POST with headers etc.  A lot of us (most of us?  all of us?)
make use of this to test out the api's before we write code---just do the
GETs, POSTs and PUTs through a browser, copying and pasting the right URL's
that through code we would get through RDF parsing.

But this actually can be a viable technique for some quick integrations.
If the end user can get at the needed resources (maybe through GETs from
another tool or a dedicated export), then the end user can also do the
POST.  So imagine (and I have in my pocket a good example that's not public
info yet if anyone wants to communicate privately) a tool that could
generate a fairly large set of resources that would be good to POST to
another tool through OSLC.  The first tool could generate a set of RDF/XML
files in the format the other tool expects.  Maybe the vendor can commit
the resources to do that, or it could be through a field services contract.
Then the end user could use a browser plugin to GET the services document
from the receiving tool, choose the desired creationFactory and POST the
resources.  If the POST would support multiple resources, this is easy for
the customer---have a "canned" POST setup in the browser plugin, log into
the actual tool (which gives the browser plugin authorization!), and select
the exported file and send the POST command.  This is very easy if there's
one file for all the resources.  If it's one at a time, it's quite a bit
more painful (the degree of pain is linear in the number of resources!).
Since it's "just as easy" for the server to handle the multiple posts
(well, with the exceptions about error handling noted earlier of course!!
nothing is really easy!), this would help customers put tools together
easily, which is the point of OSLC.  And the error handling is a small
problem for a server writer (compared to all the error handling you have to
do anyway to make sure the POST is valid), at the saving for multiple end
users.

I'd be happy with this being a "should" or "may" in the spec rather than
"must" (perhaps with some standard error message if it's not supported, or
something in the services document, so that clients that are written in
code can tell) and the receiveing vendor can decide if its customers would
get value from it.

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html