Enhancement
Domain REST API
Issue description
It should be possible to send POST requests to virtual topic type resources to create and modify respective instances. One can think of different representations to be accepted but one seems to be the most obvious: a JSON representation using the serialization names.
Developer comments
The access rights are applied directly to the REST API, so in order to create an instance of certain type, the user needs the respective right. It should be considered whether the rights on a field level from that are applied to the form should be enfored here as well.
This revives [1498, the issue to support TM/JSON].
The basic documentation of the API should be generated from the model and there should be a single simple way to access it like %… --help% or %man …% on the unix shell.
No to the above. The documentation is already given in the .pi. It just needs be tailored a bit to satisfy the REST point of view. This is moved to [14347, another issue].
I do not think this should be realized with a meta service as these are exclusively accessible for the user group administrator. I do not want to soften that.
A POST HTTP request to create something new should look like this:
Body contains a TMJSON representation of an instance of a topic type, or an array thereof. If it is an array there is no need for the instances to be of the same topic type, but %instance_of% aka %type% must be present. If the TMJSON contains an %id% attribute the referred topic is located. This indicates an update. If not found it is a bad request. The attribute can either be a system id or a topic reference or an array thereof. Only an absent id attribute signals that you want to create something new.
Some ideas for the resource.
[%STORE_URL/rest/
STORE_URL/rest/person/
STORE_URL/rest/company/%]
Singular/Plural should not matter, but singular is recommened.
[%STORE_URL/rest/orders/
STORE_URL/rest/order/%]
Instances are accessible by appending the id. They accept GET, POST and DELETE.
[%STORE_URL/rest/person/1234%]
Lazy option:
[%STORE_URL/rest/1234 %]
Content-Type headers are optional. TMJSON is the only supported format and used by default.
Client errors will 40x. The body is a natural language text giving the reason for the error (= the exception message). Probably there is only a need to distinguish insufficient rights 401 and bad request 400.
Alternatively we could just POST to the store URL (again) and use the extension ".json" and the mime type "application/json".
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.