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 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html
