Thanks all for the quick response and I will continue with those comments.
On Tue, Mar 29, 2016 at 4:17 PM, Joseph Fonseka <jos...@wso2.com> wrote:
> Hi
>
> Having different ways to retrieve the configs of the resource will affect
> the intuitiveness of the API so IMO having a uniform way of retrieving the
> configs will be more beneficial.
>
> Alternate solutions for the given problem.
> 1. You always return the configs as part of the specific resource. Ex. /
> analysis/{analysis_id} and give the option of turning off configs as a
> query parameter Ex /analysis/{analysis_id}?configs=false.
> 2. Further more you can filter configs with /analysis/{
> analysis_id}?configs=attribute.
> 3. If you want to do a partial update of configs you can use sub resource
> or a controller resource. Ex. /analysis/{analysis_id}/configs, /
> analysis/update-config
>
> Regards
> Jo
>
> On Tue, Mar 29, 2016 at 3:31 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
>> 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
>>
>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
