[Hawkular-dev] REST ideas

[Libor Zoubek]

I'd like to bring

4. when returning collections from api. I think we should not stick with  
simply returning an array of objects. When we in future realize we need to  
include paging info or other helper data, we'd have to break the API and  
transform the response to somethine like

{
  "result":[{....},{...}],
  "paging"...
}

Yes .. in case of paging, we can put it into HTTP headers, but for client  
it is much easier to reach paging info from the response.

So simply wrapping returned array into response object does not hurt at  
all, brings consistency (data is always provided under same key "result")  
and extensibility.

I can see this trend in other projects - Foreman's moved to this concept  
in REST APIv2, and ie. djangorestframework or Kodi.

Libor

Dne Wed, 11 Feb 2015 14:23:34 +0100 Viliam Rockai <vrockai at redhat.com>  
napsal(a):

> Hi,
>
> I'm looking at hawkular-inventory and I've got several comments (liveoak
> legacy) which could apply on other rest endpoints, too:
>
> 1. I think it would be easier to use/get if we make it more
> hierarchical. That means; instead of using two distinct URLs (resources
> vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> only one (/hawkular/inventory/rest-test/resources/x1422733176502).
>
> 2. Sometimes, in the docs, attribute called "name" is used, and referred
> to, as an "id". Would it be possible and make sense to choose just one
> notation and use it in the representation?
>
> 3. Usage of methods: When you want to create a metric, you use the PUT
> method. What about unifying methods in some commonly used manner. Like
> post for create, put for edit?
>
> WDYT?
>
> Viliam
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


-- 
Libor Zoubek