Skip to content

get Support (Basic). #2

@steve-r-west

Description

@steve-r-west

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:

  1. The ability to make HTTP calls.
  2. The ability given a resource type to know the URL.
  3. The ability to pass in supplied ids.
  4. 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 the most basic, which is just supporting HTTP calls, while other tickets bootstrap other parts of it.

So for this ticket a call to epcc get blargh should call GET /v2/blarg. Other tickets will support meta data and other parts of this feature.

An http 2xx should have a zero exit code to the os, an 3xx should be auto followed, and a 4xx or 5xx should have a non zero exit code to the OS.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions