The get command will eventually have the following semantics.
get <RESOURCE> query parameters
or
get <RESOURCE> <ID_1> <ID_2> query parameters
Some examples
epcc get customers foo Should call GET /v2/customers/foo
epcc get customer-address foo bar should call GET /v2/customers/foo/address/bar
epcc get customer foo include address should call GET /v2/customers/foo?include=address
epcc get customers page[offset] 100 should call GET /v2/customers?page[offset]=100 (although the page[offset] should be url encoded).
In order to build this out we need:
- The ability to make HTTP calls.
- The ability given a resource type to know the URL.
- The ability to pass in supplied ids.
- The ability to handle passing query parameters to the call.
- This is particularly challenging, and in the bash version, I wasn't sure how the CLI could distinguish between whether or not
epcc get customers foo bar means GET /v2/customers?foo=bar or GET /v2/customers/foo?bar.
The scope of this ticket is to build off the work of #2 and #3 and support calls to the right URL, potentially supplying ids.
Acceptance Criteria
So for instance at the end of this ticket, the following calls should work:
epcc get account ==> GET /v2/accounts/
epcc get account foo ==> GET /v2/account/foo
epcc get account-memberships foo ==> GET /v2/accounts/foo/account-memberships
epcc get account-memberships foo bar ==> GET /v2/accounts/foo/account-memberships/bar
The following calls should give errors that are useful to users.
epcc get blarg should complain that there is no resource named blarg, in a friendly error message, and return a non zero exit code.
epcc get account-memberships should complain that a required is missing, and exit with a non zero status.
You can not worry about excess parameters for this ticket, and a follow up ticket will fix it.
The
getcommand will eventually have the following semantics.get <RESOURCE> query parametersor
get <RESOURCE> <ID_1> <ID_2> query parametersSome examples
epcc get customers fooShould callGET /v2/customers/fooepcc get customer-address foo barshould callGET /v2/customers/foo/address/barepcc get customer foo include addressshould callGET /v2/customers/foo?include=addressepcc get customers page[offset] 100should callGET /v2/customers?page[offset]=100(although the page[offset] should be url encoded).In order to build this out we need:
epcc get customers foo barmeansGET /v2/customers?foo=barorGET /v2/customers/foo?bar.The scope of this ticket is to build off the work of #2 and #3 and support calls to the right URL, potentially supplying ids.
Acceptance Criteria
So for instance at the end of this ticket, the following calls should work:
epcc get account==>GET /v2/accounts/epcc get account foo==>GET /v2/account/fooepcc get account-memberships foo==>GET /v2/accounts/foo/account-membershipsepcc get account-memberships foo bar==>GET /v2/accounts/foo/account-memberships/barThe following calls should give errors that are useful to users.
epcc get blargshould complain that there is no resource named blarg, in a friendly error message, and return a non zero exit code.epcc get account-membershipsshould complain that a required is missing, and exit with a non zero status.You can not worry about excess parameters for this ticket, and a follow up ticket will fix it.