Can not POST updates to /config/application or other resoruces

[jgruber]

Unit compiled from the master branch.

In the manual Configuration section it references:
POST Updates the array at the request URI, appending the JSON value from the HTTP request body.
I looked at the code and saw that the path length is checked in the controller, but just wanted to report that trying to use unit as described in the Configuration doc, is not obvious.

I have the following configuration applied successfully:

bash-5.0# curl -v --unix-socket /var/run/unit/control.sock http://localhost/config
*   Trying /var/run/unit/control.sock:0...
* Connected to localhost (/var/run/unit/control.sock) port 80 (#0)
> GET /config HTTP/1.1
> Host: localhost
> User-Agent: curl/7.65.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Unit/1.11.0
< Date: Wed, 04 Sep 2019 21:50:20 GMT
< Content-Type: application/json
< Content-Length: 707
< Connection: close
< 
{
	"listeners": {
		"127.0.0.1:8102": {
			"pass": "routes"
		}
	},

	"routes": [
		{
			"match": {
				"uri": "/TrustedDevicesUI*"
			},

			"action": {
				"pass": "applications/trusteddevices"
			}
		},
		{
			"match": {
				"uri": "/TrustedDevices*"
			},

			"action": {
				"pass": "applications/trusteddevices"
			}
		},
		{
			"match": {
				"uri": "/TrustedProxy*"
			},

			"action": {
				"pass": "applications/trusteddevices"
			}
		}
	],

	"applications": {
		"trusteddevices": {
			"type": "external",
			"working_directory": "/var/lib/f5-icontrol-trusted-devices",
			"executable": "unitapp.js",
			"user": "nginx",
			"group": "nginx"
		}
	}
}
* Closing connection 0

Then I try to add an additional application using POST.

bash-5.0# curl -X POST -d '{"testunitapp":{"type":"external","working_directory":"/var/lib/test-unit-app","executable":"bin/www","user":"nginx","group":"nginx"}}' -v --unix-socket /var/run/unit/control.sock http://localhost/config/applications
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying /var/run/unit/control.sock:0...
* Connected to localhost (/var/run/unit/control.sock) port 80 (#0)
> POST /config/applications HTTP/1.1
> Host: localhost
> User-Agent: curl/7.65.1
> Accept: */*
> Content-Length: 134
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 134 out of 134 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
< Server: Unit/1.11.0
< Date: Wed, 04 Sep 2019 21:50:28 GMT
< Content-Type: application/json
< Content-Length: 41
< Connection: close
< 
{
	"error": "Method isn't allowed."
}
* Closing connection 0
`
and get a 405 Method not allowed response.

We need to either update the Configuration doc to show that POST is only for attributes or make it work. 

Naturally merging the JSON and issuing a PUT for the entire configuration works fine.

[VBart]

POST | Updates the array at the request URI, appending the JSON value from the HTTP request body.

But the applications object is a JSON object, it's not an array. Could you suggest changes that will make the application of the POST method more clear?

The POST operation can safely work in cases when the index isn't know and can be assign automatically. If we allow it for objects with either merge semantics or replace, then we will violate the HTTP specification, because the POST method has to be non-idempotent operation.

P.S. What do you mean by POST is only for attributes? The array/object terminology comes from JSON. What is attributes in this context?

Every word matters. :)

Frankly, though, I've had similar considerations when trying to POST-update single values in match conditions: "host": "foo" -> "host": ["foo", "bar"]

[VBart]

@artemkonev
When you POST-ing an object to another object: {"host": "foo"} to {"host": [ ... ] } - there other problems arise, because it implies some merging semantics. What if multiple members of objects match? What if they match on deeper level? How deep we should check? Even your case is different from the ticket, because your case has a matching member host with an array inside, while the case in the ticket is about POST-ing {"testunitapp": ... } to {"trusteddevices": ... } (no matching members and no arrays).

So, even if we allow something like that, then it will be complex operation, which is hard to describe, hard to use correctly. The idea of what should be merged and users expectations can be different.

[i4ki]

I agree with @VBart.

I also agree that POST is loosely defined in the RFC and that leads to any kind of usage, but luckily the community (following the Roy Fielding REST dissertation) have been using it mostly to cases when you need to add a new resource to the set of existing resources and you are not interested in the resource id (or key) created for it. Eg.: creating posts in a social network, appending data in general, sending events, and so on.

That's not OP case, as he wants to add an application of name "testunitapp".

For the complex case of merging data, the PATCH HTTP verb was created recently, but it's often used incorrectly, there is no easy way to expose a user API for it, as the patch instructions can be complex and app-specific.