[EnMasse] Upcoming REST API changes

[Rob Godfrey]

On 8 May 2018 at 11:02, Gordon Sim <gsim at redhat.com> wrote:

> 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.


Agreed - but I think this only makes sense in the context of creating
multiple addresses within a single address space.


>
>
> 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
>>
>
>
Will it be possible to use the URL query / labelSelector in the PUT/DELETE
as well as GET?  Otherwise I presume you are first going to need to query
for the address "name" using a GET (since the name may must essentially
just be an ID for an (addressSpace, address) pair).


> 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.
>
>
I prefer this form - it is much more natural from a usability perspective.

Further, when we talk about "addressSpace" and "address" here, are we
talking about the names as the user will understand them (i.e. not bound by
kubernetes naming restrictions) or some sort of mangled form are valid
kubernetes names?

-- Rob


> _______________________________________________
> enmasse mailing list
> enmasse at redhat.com
> https://www.redhat.com/mailman/listinfo/enmasse
>



-- 
____________________________________________________________
_________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20180508/278f706a/attachment.htm>