One of the most debated topics during the development of the OSLC-CM 1.0 specifications was around resource creation. Many different approaches were discussed. First there were some traditional methods, where the consumer learns about what properties are needed, their types, constraints, etc and then appropriately builds a request body to POST to a given resource factory URI. Another approach is to agree on what a simple resource should look like, then have a resource factory URI that will accept these and in most cases will respond with a 201-Created and a URI for the new resource.
One of the most powerful features of the OSLC-CM 1.0 spec is the ability to delegate UIs for certain functions. Most (if not all) CM applications have a complex Web UI form used to collect all the required, dependent and typed fields; apply some validation, then commit the changes to its repository. We can leverage that already working fine Web UI form, apply some rules to it and then leverage it within other contexts. Applying these rules, or techniques, we can communicate across web applications that run within web browsers to communicate when the resource is created.
One other challenge to this approach it how to prefill a form, a key aspect of scenarios in CM integrations. It is not feasible to do more URL path building, which is fragile and has size limits. So we created a discoverable URL for posting some resource data and the result would be a URL to a prefilled form. This follows the some model as creating resources in REST, though in this case the resource is a form.
