Re: [Hawkular-dev] REST ideas
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Libor Zoubek