Hi, When designing API, we need to let the clients know the API endpoints so they can invoke relevant endpoint to fetch expected resource. Assuming size of the configuration/analytic object payload is a dynamic thing, how can the client know which endpoints to invoke to fetch the required resource. How does the client know the size of the analytic payload. In this case how does a client know which API endpoint to invoke if he want to get configs. It may be GET /analysis if analysis size is low, otherwise GET /analysis/configs .
Yes, we can not go extreme in fine grain or coarse grain. IMO best approach is to go in middle path, define a reasonable set of endpoints to fetch resources. On Tue, Mar 29, 2016 at 3:08 PM, Thamali Wijewardhana <tham...@wso2.com> wrote: > Hi, > > When creating a REST API to WSO2 machine learner, one of the important > problems I faced was selection among fine grained resources and coarse > grained resources. In other words, whether to define something as a > separate resource or a part of a large resource. > > Fine grained Resources are low complex and easy to maintain. But it can > make data become an inconsistent state and the server will end up receiving > higher number of HTTP requests possibly impacting its ability to serve > multiple API consumers. > > In using coarse grained resources, the data inconsistency and higher load > on the server is reduced. But it may be difficult to maintain and higher > JSON payload may be returned. > > For example, we have an API GET api/analysis/analysis_id/configs which > retrieves configurations of an API. The problem is whether to use a > separate resource for configs or return configs with the analysis resource. > If we consider configuration as a separate resource, we have to define an > API, GET api/analysis/analysis_id/configs. But if we return configs with > analysis resource, then it may be only the API GET > api/analysis/analysis_id and the configuration should be added to analysis > resource and returned with it. > > I have found an approach to solve the problem and given below is what I > have understood. > > The decision should be taken considering the situation. > > Here, the decision is based on the size of the configuration object. If it > has a large size, then if we return it with analysis resource, it may be a > large JSON payload and time wastage because every time an analysis resource > is returned configuration also have to be returned even not necessary. > Therefore, if configuration is large, it is better to use a separate > resource for configurations and use a separate API as > api/analysis/analysis_id/configs > > But, when we have to access a simple property such as algorithm-name of > the analysis, then it is better to return it with algorithm resource. > > This is the approach I have decided and highly appreciate your suggestions > on this. > > > Thanks > > > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
