Functional tests as User Stories
by Justin Harris
I don't know if anyone has heard of Cucumber (http://cukes.info/) - its a BDD framework in ruby, but it seems like a nice way to define specific user stories that are directly executable. Has anyone played around with this? It could be a nice fit for candlepin...
- Justin
14 years, 3 months
Todays Wadl
by Bryan Kearney
Which is funny to say...
Looking through the wadl today.. i assume the following are still
ongoing changes:
/pools/consumer/cid becomes /pools?consumer=cid
We Add a /consumers/{cid}/products
/entitlements/consumer/{consumer_uuid}/ becomes /entitlements?consumer=cid
/entitlements/consumer/{consumer_uuid}/product/{product_id} becomes
/entitlments?consumer=cid&product=pid
-- bk
14 years, 3 months
RFC: API changes
by Bryan Kearney
Per the IRC thread. He is a complete set of proposals with any backing
referneces I have for them. If we agree to any of these, I would suggest
we look to implement after this sprint in order to not scuttle the work
of the client guys:
1:: Plurals
-----------
No real reference, but is looks like most folks use /owners /customers
/jedi instead of /owner /customer /jedum.
2:: Put and POST
----------------
I think we are are ok, here, but look at:
-
http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/
-
http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_...
- http://code.google.com/p/django-rest-interface/wiki/BestPractices
I think we want to go with the model of PUT being idempotent, and it is
used when you know "everything". If you know some thing, or need a query
parameter.. it is a POST.
3:: Rest is not RPC, Resource Addresability, URL Structure
---------------------------------------
This is a crap shoot of stuff, but looking at
-
http://blog.linkedin.com/2009/07/08/brandon-duncan-java-one-building-cons...
- http://www.slideshare.net/calamitas/restful-best-practices (first part)
- http://code.google.com/p/django-rest-interface/wiki/BestPractices
It seems like we would want every resource would have a permanent uri
which is:
/{resources1}/{id}
And that we could provide readable uris for important relationships
/{resources1}/{id}//{resources2}/{id}
and adopt the pattern that collections can be filterable based on query
parameters:
/{resources1}?foo=bar
in part of this,
PUTTING IT ALL TOGETHER
=======================
I think the following APIS which are docuemnted at:
https://fedorahosted.org/candlepin/wiki/API
would change
registerConsumer (aka POST /consumer):
POST /consumers
unregisterConsumer (aka DELETE /consumer/{cosumer_uuid}):
DELETE /consumers/{consumer_uuid}
syncCertificates (aka POST /consumer/{consumer_uuid}/certificates):
POST /consumers/{consumer_uuid}/certificates
This is a bit off standard, but I think we are ok
bind:
POST /entitlement/consumer/{consumer_uuid}/product/{product_id}
becomes
POST /consumers/{consumer_uuid}/entitlements?product={product_id}
POST /entitlement/consumer/{consumer_uuid}/token/{registration_token}
becomes
POST /consumers/{consumer_uuid}/entitlements?token={registration_token}
POST /entitlement/consumer/{consumer_uuid}/pool/{pool_id}
becomes
POST /consumers/{consumer_uuid}/entitlements?pool={pool_id}
All of these should return a new entitlement
getEntitlementPools (aka GET /entitlementpools/consumer/{consumer_uuid}/ ):
GET /pools?consumer={consumer_uuid}
GET /entitlement/consumer/{dbid}/:
GET /consumers/{dbid}/entitlements or
GET /entitlements?consumer={dbid}
GET /owner/{dbid}/entitlement:
GET /owners/{dbid}/entitlements or
GET /entitlements?owner=dbid
Many other changes, but all variations on the same theme.
Thoughts, Comments, Criticisms?
Next up, which can be done later, is
* HATEOAS
* Paginating Collections
* Versioning
-- bk
14 years, 3 months
Re: RFC: API changes
by jesus rodriguez
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/05/2010 10:21 AM, Jeff Ortel wrote:
>
> Would it be better to have a serial number resource which the client
> makes a GET request against (no params except maybe consumer_uuid)
> which would return ALL serial numbers, then let the client do the
> diff making a request for any missing certificates?
>
> GET /consumer/{consumer_uuid}/serialnumbers/
>
> Response would be a list of serial numbers, client diffs this
> list with its current list. Any diff, would be a call to
>
> GET /consumer/{consumer_uuid}/certificates?serials=missingserial1,ms2,m4
>
>> RESTful (ness) aside, how is this different then what dgoodwin has proposed?
The difference is the client is doing the diff, and the url
is different :)
jesus
- --
jesus m. rodriguez | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management | 919.754.4413 (w)
rhce # 805008586930012 | 919.623.0080 (c)
+---------------------------------------------+
| "Those who cannot remember the past |
| are condemned to repeat it." |
| -- George Santayana |
+---------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkuRI5gACgkQvJZ57YntiYP1ZwCeOduAqOhuKRFH1s2dQOABOcZV
x80AoMmQtEYrSNNIprE9WPX9NKTY2gxV
=XBCK
-----END PGP SIGNATURE-----
14 years, 3 months
nullpointerexception could occur
by Jesus M. Rodriguez
EntitlementResource has this code in it, o.getClass() will cause a NPE.
private void verifyExistence(Object o, String id) {
if (o == null) {
throw new RuntimeException(o.getClass().getName() + " with ID: [" +
id + "] not found");
}
}
jesus
14 years, 3 months
Following up on the call today
by Bryan Kearney
Ok.. just following up on call today relative to cert libraries.
My assumption is that we will continue with the model of
ConsumerIdentityCertificateCurator getting identity certificates and the
CertificateServiceAdapter for getting entitlement certificates. If the
default implementation of the CertificateServiceAdapter happens to
respond with x.509.. they may use the same libraries.
Is that correct?
-- bk
14 years, 3 months
What Are curators?
by Bryan Kearney
Questoin for you guys... what are curators? Are they:
1) Data Objects which hide the Persistenct Logic?
2) Business Logic Objects?
3) Both?
I ask because I see the entitler.. and I also see logic in the
EntitlementPoolCurator.
-- bk
14 years, 3 months
Re: Following up on the url structure
by Justin Harris
----- "Bryan Kearney" <bkearney(a)redhat.com> wrote:
> On 03/02/2010 09:54 AM, Dmitri Dolguikh wrote:
> > On 03/02/2010 09:41 AM, Bryan Kearney wrote:
> >> I checked in a quick model based on the discussions from yesterday.
> I am
> >> playing around with owners and pools since it is out of the way of
> the
> >> client code, and displays the pattern we have been chatting about.
> If
> >> you pull the latest you will see the following urls
> >>
> >> GET /owner/1/pool gives you all the pools for owner 1
> >>
> >> GET /pool gives you all the pools
> >>
> >> GET /pool?owner=1 gives you all the pools for owner 1
> >>
> >> GET /pool?product=SPACEWALK-001 gives you all the pools for the
> >> specified product
> >>
> >> GET /pool?product=SPACEWALK-001?owner=1 gives you all the pools for
> the
> >> specified product and owner
> >>
> >> I like this pattern because it recoginizes that pools and owners
> are
> >> first class resources, and that there is a "Blessed" relationship
> of
> >> owners having pools. Everything else is a query parameter. Neither
> of
> >> these should support adding (since you dont add pools) but if they
> did I
> >> would assume there would be support for POST/PUT at both:
> >>
> >> /pool and /owner/{id}/pool
> >>
> >> Now.. if we move this pattern out to the rest of the API..I think
> it
> >> really only effects a few of the APIs. I think it would effect
> >>
> >> GET /entitlement/consumer/{dbid}/product/{dbid}
> >> GET /entitlement/consumer/{dbid}/ :
> >>
> >> which would become
> >>
> >> GET /consumer/{dbid}/entitlement with some query parameters
> >> or
> >> GET /entitlment with some query parameters
> >>
> >> It would also effect the POSTS, which would be off of /entitlment
> or
> >> /consumer/entitlement
> >>
> >> Thoughts?
> >>
> >> -- bk
> >> _______________________________________________
> >> candlepin mailing list
> >> candlepin(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/candlepin
> >>
> >
> > i do like the differentiation between first class relations and the
> > rest. I actually find it cleaner.
> > -d
>
>
> Continuing this thread.. I just pushed in support for
>
> GET /pool?consumer={consumer_uuid}
>
> which would replace (I think) the getEntitlementPools client API which
>
> is currently set to be
>
> GET /pool/consumer/{consumer_uuid}/
>
> which I think is a better fit.. since the client could do the
> following
> if they wanted:
>
> GET /pool?consumer={consumer_uuid}&product={product_id}
What is the semantics of this?
My thought was that query parameters == filters for collections (such as /pools).
So are these entitlement pools that are available to the given consumer? This feels a little strange to me.
perhaps the query would be through the consumer resource?
GET /consumers/4/pools - available entitlement pools for the consumer
GET /consumers/4/entitlements - current entitlements for the consumer
>
>
> Thouhgts? Am I off base on this?
>
> The rules I am coming back to is this:
>
> GET /RESOURCE is a collection of resources
> GET /RESOURCE?{queryString} is a filtered collection of resources
> GET /RESOURCE/{id} is a specific resource
> GET /RESOURCE/{id}/SUBRESOURCE is a specific collection of child
> resources which could also be represented as
> /SUBRESOURCE?resource={id}
>
> If we want to get nutty, then we could do
>
> GET /RESOURCE/{id}/SUBRESOURCE/{sid} is a specific item from the
> child.
> Note, this can also be represented as GET /SUBRESOURCE/{sid}
>
> GET /RESOURCE/{id}/SUBRESOURCE?{query_string} is a filtered collection
>
> of children. Note, this is the same as /SUBRESOURCE?{query_string}
> with
> an extra resorce={id}
>
> -- bk
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
14 years, 3 months
Following up on the url structure
by Bryan Kearney
I checked in a quick model based on the discussions from yesterday. I am
playing around with owners and pools since it is out of the way of the
client code, and displays the pattern we have been chatting about. If
you pull the latest you will see the following urls
GET /owner/1/pool gives you all the pools for owner 1
GET /pool gives you all the pools
GET /pool?owner=1 gives you all the pools for owner 1
GET /pool?product=SPACEWALK-001 gives you all the pools for the
specified product
GET /pool?product=SPACEWALK-001?owner=1 gives you all the pools for the
specified product and owner
I like this pattern because it recoginizes that pools and owners are
first class resources, and that there is a "Blessed" relationship of
owners having pools. Everything else is a query parameter. Neither of
these should support adding (since you dont add pools) but if they did I
would assume there would be support for POST/PUT at both:
/pool and /owner/{id}/pool
Now.. if we move this pattern out to the rest of the API..I think it
really only effects a few of the APIs. I think it would effect
GET /entitlement/consumer/{dbid}/product/{dbid}
GET /entitlement/consumer/{dbid}/ :
which would become
GET /consumer/{dbid}/entitlement with some query parameters
or
GET /entitlment with some query parameters
It would also effect the POSTS, which would be off of /entitlment or
/consumer/entitlement
Thoughts?
-- bk
14 years, 3 months
