As Sanjeewa pointed out, I also think we should support pagination related parameters; eg: "count", "limit", "offset", "next", "previous", "total"; where the total is the number of total "active" tenants in the system.
On Mon, Aug 12, 2019 at 6:54 PM Malintha Amarasinghe <[email protected]> wrote: > > > On Mon, Aug 12, 2019 at 6:38 PM Malintha Amarasinghe <[email protected]> > wrote: > >> >> >> On Mon, Aug 12, 2019 at 6:17 PM Nuwan Dias <[email protected]> wrote: >> >>> Ideally we would need to support getting all tenants. But for now I >>> think its ok to support the active state only. Using the query param to >>> pass in the state gives us the flexibility to support other (inactive) >>> states in the future. >>> >>> I also think at this moment we do not need to support retrieving >> inactive tenants. We can think of state = "active" as default and simply >> omit the active param (i.e: I think we do not even need to support state >> param unless we support inactive tenants because the only state we support >> is "active"). Then GET /tenants will give all the active tenants. >> >> >>> Regarding the other tenant specific APIs, I don't see a need to support >>> them right now unless we have a business requirement to do so. >>> >> +1 >> >> >>> On Mon, Aug 12, 2019 at 6:05 PM Dushan Silva <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> *Few clarifications* >>>> We decide to write this rest endpoint to retrieve active-tenants, In >>>> addition to this is there a requirement where we would need to get inactive >>>> tenants ? >>>> >>>> what @Thilini Shanika <[email protected]> said makes senses its better >>>> if we can retrieve some important information such as tenantId, domain.. >>>> anything else that we should return may seem significant for this api? >>>> >>> tenantId and tenantDomain would be the most needed ones. >> >> Sorry, ignore the above comment "tenantId and tenantDomain would be the > most needed ones.". > tenantId is an auto-incremented ID so I don't think we should expose this > as it would expose the number of total tenants in the system. And, at the > store, we only need tenantDomain. I think it would be enough to list only > the tenantDomain. WDYT? > We can add "status" : "active" at each tenant object level to explicitly > say the tenant is active. > > > >> >>>> On the other hand would we need to add few more tenant specific APIs >>>> such as getting all tenant details, getting tenant by tenantId etc ? >>>> currently we only needed to get the active tenants for UI purposes. WDYT >>>> @Nuwan >>>> Dias <[email protected]> @Sanjeewa Malalgoda <[email protected]> >>>> >>>> Thanks >>>> >>>> On Mon, Aug 12, 2019 at 5:46 PM Dushan Silva <[email protected]> wrote: >>>> >>>>> adding architecture >>>>> >>>>> On Mon, Aug 12, 2019 at 5:34 PM Sanjeewa Malalgoda <[email protected]> >>>>> wrote: >>>>> >>>>>> Yes, Nuwan is correct here. State is filter criteria and using query >>>>>> parameters is recommended. Also when we fetching this sort of resources >>>>>> its >>>>>> always good to have a way to limit and paginate number of results return. >>>>>> @Everyone i can see many team mates need to update API and add/modify >>>>>> resources. In that case schedule meeting and discuss about all resource >>>>>> is >>>>>> good IMO. >>>>>> >>>>>> Thanks, >>>>>> sanjeewa. >>>>>> >>>>>> On Mon, Aug 12, 2019 at 5:26 PM Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> We have to discuss this publicly guys. >>>>>>> >>>>>>> Shouldn't this be /tenants?state=active? >>>>>>> >>>>>>> On Mon, Aug 12, 2019 at 5:19 PM Dushan Silva <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> We are planning to add a REST API endpoint to APIM 3.0 Store REST >>>>>>>> API to get all the tenant active tenant domains. Shown below is the >>>>>>>> swagger >>>>>>>> related to the new rest api. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *####################################################### The >>>>>>>>> tenant resource >>>>>>>>> APIs######################################################'/tenants/active-tenants': >>>>>>>>> #-------------------------------------------------------- # Retrieve >>>>>>>>> all >>>>>>>>> active tenants >>>>>>>>> #-------------------------------------------------------- >>>>>>>>> get: security: - OAuth2Security: - [] summary: | >>>>>>>>> Get all active tenants names description: | This operation is >>>>>>>>> to >>>>>>>>> retrieve all active tenants tags: - active tenants >>>>>>>>> responses: >>>>>>>>> 200: description: | OK. Tenant names >>>>>>>>> returned. >>>>>>>>> headers: Content-Type: description: | >>>>>>>>> The content type of the body. type: string schema: >>>>>>>>> type: '#/definitions/TenantList' 404: description: | >>>>>>>>> Not Found. Requested application does not exist. >>>>>>>>> schema: >>>>>>>>> $ref: '#/definitions/Error' 406: description: | >>>>>>>>> Not Acceptable. The requested media type is not supported >>>>>>>>> schema: $ref: '#/definitions/Error'* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *#-----------------------------------------------------# The >>>>>>>>> Tenant List >>>>>>>>> resource#----------------------------------------------------- >>>>>>>>> TenantList : title: Tenant list properties: count: >>>>>>>>> type: >>>>>>>>> integer description: | Number of tenants returned. >>>>>>>>> example: 1 list: type: array items: type: >>>>>>>>> string* >>>>>>>> >>>>>>>> >>>>>>>> I have decided to use the resource as */tenants/active-tenants. * >>>>>>>> >>>>>>>> */**tenants *was used at the start of the path as if we are >>>>>>>> planning on adding any other tenant specific rest apis we can keep >>>>>>>> using >>>>>>>> this path. >>>>>>>> >>>>>>>> Any input for this is highly appreciated. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Best Regards >>>>>>>> Dushan Silva >>>>>>>> Software Engineer >>>>>>>> >>>>>>>> *WSO2, Inc. * >>>>>>>> >>>>>>>> lean . enterprise . middleware >>>>>>>> Mob: +94 774 979042 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>>>> (m) +94 777 775 729 | (e) [email protected] >>>>>>> [image: Signature.jpg] >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Sanjeewa Malalgoda* >>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>>>>> (m) +94 712933253 | (e) [email protected] | (b) Blogger >>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>>>>> <https://medium.com/@sanjeewa190> >>>>>> >>>>>> GET INTEGRATION AGILE <https://wso2.com/signature> >>>>>> Integration Agility for Digitally Driven Business >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards >>>>> Dushan Silva >>>>> Software Engineer >>>>> >>>>> *WSO2, Inc. * >>>>> >>>>> lean . enterprise . middleware >>>>> Mob: +94 774 979042 >>>>> >>>> >>>> >>>> -- >>>> Best Regards >>>> Dushan Silva >>>> Software Engineer >>>> >>>> *WSO2, Inc. * >>>> >>>> lean . enterprise . middleware >>>> Mob: +94 774 979042 >>>> >>> >>> >>> -- >>> *Nuwan Dias* | Director | WSO2 Inc. >>> (m) +94 777 775 729 | (e) [email protected] >>> [image: Signature.jpg] >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> > > > -- > Malintha Amarasinghe > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 > -- Malintha Amarasinghe *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
