Accessing a Resource's State

[duglin]

Is there any reason why "state" isn't just part of each object instead of under a different url (e.g. /resource/state) ? It would be good if each object had "state" (just like each has "labels") to provide some consistency. Then a user can GET a resource and see it all in one response object instead of having to GET /resource and GET /resource/state.

This would then also allow for a more consistent pattern between sync and async - meaning doing a GET on a resource URL will always tell us what's going on with it.

[KirilKabakchiev]

It's currently included as both options. If you look at the service instances / bindings responses they currently include the state in the response. There is also the separate subresource API for each resource (for example service_instances/service_instance_id/state. I agree that one of the approaches should be chosen.

What I am not 100% if this state and all its conditions would be required by any client - the CLI will probably not need so detailed information for visualization and the business logic for processing and reconciling the state would probably (atleast at first) be running in the same Go process (be it async of the API or not). So returning the whole state in each api response might or might not be too much ?

Another option is the create / delete / patch apis to not include state and just returh 202 and location header . Then this location (most probably the get api for the resource) can include details about the resource state/status

[duglin]

I'd prefer to start with the simple approach.... GET returns it all. Then if we find that too much info is returned we can then optimize things. E.g. add a "?skipConditions=true" type of thing or some other filtering mechanism. But starting out with the approach of 2 GETs just to get a resource's full set of metadata will probably really annoy people.

[KirilKabakchiev]

I agree, let’s start simple with no subresource apis.

Next interesting point would be - do all apis (create, patch, delete,get) also return a state or another option would be for them to just return 202 and location of the get api - the get api would then include state

[duglin]

See: #36

[KirilKabakchiev]

Added some details in #31 on that.