[EnMasse] Upcoming REST API changes

[Gordon Sim]

On 08/05/18 04:17, Ulf Lilleengen wrote:
> For addresses, the REST API also changes in the same way, making the 
> addresses scoped by both namespace and address space. The 
> metadata.addressSpace field will be mandatory now that it cannot be 
> inferred from the URL path anymore.
> 
> Creating multiple addresses at once using AddressList is removed, as 
> this is handled client-side when using the kubectl command line and not 
> server-side. We could still keep it at server side if we think it will 
> be of value.

To create 10,000 addresses, I think one request with a large payload 
might be simpler than 10,000 separate requests.

> To create addresses:
> 
> POST /apis/enmasse.io/v1/namespaces/myproject/addresses
> 
> To retrieve all addresses:
> 
> GET /apis/enmasse.io/v1/namespaces/myproject/addresses
> 
> To retrieve all addresses for a given address space:
> 
> GET 
> /apis/enmasse.io/v1/namespaces/myproject/addresses?labelSelector=addressSpace%3Dmyspace 
> 
> 
> To update an address (to update plans for instance. More on what will be 
> allowed to change later):
> 
> PUT /apis/enmasse.io/v1/namespaces/myproject/addresses/addr1
> 
> To delete an address:
> 
> DELETE /apis/enmasse.io/v1/namespaces/myproject/addresses/addr1

Does that mean an address is unique within the namespace? I.e. if I have 
two address spaces in the same namespace, they cannot contain addresses 
with the same name/address? If so, I'm not sure how much value there is 
in having separate address-spaces in the same namespace. To what extent 
is that a conscious design choice as opposed to something forced on us 
by adopting CRDs?

To me, a more intuitive API would access the addresses via the 
address-space, e.g. 
/apis/enmasse.io/v1/namespaces/myproject/addressspaces/myspace/addresses/ 
and/or even directly setting the addresses as part of the address-space 
definition. That makes the containment more obvious and also scopes the 
addresses to address-space.