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 <[email protected]> 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 <[email protected]>
> 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
>> [email protected]
>> 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
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
