The call to getSiteInfo returns, among other things, a list of enableContainers.
Each of these is a hash eg: { "containerName":"bills", "assetType":0 }
Is there an exhaustive list of containerNames?
Is there an exhaustive list of assetTypes and what do the enums mean?
I have looked through the Yodlee developer's docco but can't find the answers.
There are couple of things to know about this.
This enabled containers varies depending upon which all containers are enabled for you as a customer, for example if you are interested only in bank and credit cards then this can be configured and irrespective of what other container types Yodlee supports you will get only these two container types.
Exhaustive list- bank, credits(for credit cards), loan/mortgage, bills(can have- minutes,telephone,utilities,cable_satellite,bills), insurance, stocks(for investments), miles(for Rewards) and prepay.
Asset Types- can be of 0,1,2 where all you containers which will have your asset will get 1, containers considered as liabilities will have this value as 2 and rest will have 0.
Related
Is there any public API which returns the tax names for all the states across all countries ?
Here are some APIs.
About pricing, some are completely free, some are based on usage and others have free trial versions.
Taxjar: github.com*, developers.taxjar.com
AvaTax: developer.avalara.com, www.avalara.com
USGeocoder: usgeocoder.com
FastTax: www.serviceobjects.com
SalesTaxPAL: www.salestaxpal.com
*GitHub link to the Taxjar profile since each language has its own repository.
Let's say that I'm developing an application about shopping. I have defined the following endpoints, which are quite self-explanatory:
GET /items
GET /items/{item-id}
GET /stores
GET /stores/{store-id}
Now, I want to create another endpoint that displays the price of individual item at different stores. This price information is not included in /items/{item-id} since I don't think it's suitable to be an attribute of item, and getting the list of prices requires a bit more calculation as I cannot return the object directly. I will name the endpoint /items/{item-id}/prices and expect a response like this:
[
{
"store_id": "store_1",
"price": 13.00
},
{
"store_id": "store_2",
"price": 12.99
}
]
I want to extend this further and create another endpoint that returns the price information for all items, but I'm having trouble naming this endpoint. So far I've thought of /items/prices or /items?display=prices but the former might be confusing as it matches with /items/{item-id}, and the latter just.. does not seem to make sense for me.
What is the best name to pick for my endpoint so that it stays consistent with the convention?
For all items pricelist endpoint for a single store, I'd recommend GET /stores/{store-id}/prices or GET /stores/{store-id}/pricelist.
For all items/stores pricelist, I'd use GET /items/pricelist or GET /items/*/pricelist, (both special before /items/{item-id}), which could be store-specified on demand by ?store={store-id}.
Adding prices endpoint to items would make no sense as item itself has nothing to do. It is store's responsibility to dictate the price.
I would suggest renaming stores endpoint to /stores/description/{id} and adding prices subcategory /stores/prices/by-item/{id} and /stores/prices/by-store/{id}.
I would say that for sepecfic item /prices/{store-id}/{item-id}
and for all prices /prices/{store-id}
I have the following aggregate:
Checkout (root)
Requirement: CouponRequirement, AnotherRequirement, YetAnotherRequirement
Coupon
A Checkout has many Requirements that need to be fulfilled in order for a Checkout to complete.
Each Requirement has a fulfill(data) method that is responsible for the fulfillment process.
One of those requirements is a CouponRequirement which, when fulfilled, needs to make sure there is stock for a particular coupon and reserve it.
For this to happen I need access to a CouponRepository or CouponService.
How could I tailor my design to accomodate that dependency?
FulfillRequirementCommand
function handle($cmd) {
$cho = $this->checkoutRepository->get($cmd->checkoutId);
$cho->fulfillRequirement($cmd->requirementType, $cmd->requirementData);
}
Checkout
function fulfillRequirement($reqType, $reqData) {
$req = $this->getRequirement($reqType);
$req->fulfill($reqData);
}
CouponRequirement
function fulfill($data) {
// check stock / reserve coupon
}
How could I tailor my design to accomodate that dependency?
The usual answer is that the application passes to the aggregate root any capabilities that are needed to perform its work.
In your particular case, this would probably look like an instance of a CouponService being passed to the Checkout aggregate root as an argument of the fullfillRequirement method.
Maybe I just can't have a generic fulfillRequirement and need one for each concrete type?
I would expect that to be the case; after all you've already identified one use case where the paths are different.
according to the documentation, the Create Shipment method requires the property "items" - an array of the items being shipped, for example:
{
"tracking_number": "EJ958083578US",
"comments": "Ready to go...",
"order_address_id": 1,
"items": [
{
"order_product_id": 15,
"quantity": 2
}
]
}
In our business, a shipment almost invariably contains ALL items from the relevant order.
That being the case, is there a way to create a shipment without listing all items (which would require iterating over the product line-items)? Or, alternatively, a way to include all items by default (without iterating)?
We are simply wishing to automate the process of adding tracking numbers to orders - which (as a manual process) involves uploading a csv with [order_number: tracking_number] - i.e. it self-evidently assumes that all items are being shipped. The API seems not to include that (very sensible) option, but I may be wrong.
From Bigcommerce Support:
There is not a way to add a tracking number without adding a shipment nor a way to default the shipment to include all products. This is a helpful suggestion though that I will be passing on to our Product Team for possible implementation into future versions of the API.
Unfortunately for now it is necessary that you GET to the products subresource of an order and iterate over all of the products to pull their 'id' values and 'order_address_id' values so you can generate your POST request to the shipment subresource. It is not necessary to make a GET request to the shipping address subresource directly unless you want the details of that shipping address. It is also not necessary to make a GET request to the base order object unless you want details found there or you are looking to automate the process of checking for orders ready to ship.
So assuming you know an order ID that you want to ship it should only take 2 requests total to both GET the products subresource and then POST to the shipment resource.
Let's say we are making an invoice API. What is a more appropriate resource?
GET
paid_invoices
due_invoices
all_invoices
or
GET
invoices/all
invoices/due
invoices/paid
Additional question: If your API allows marking invoices as paid what's the proper resource?
PUT //where 3 is the id
invoices/3
or
PUT
pay_invoice/3
I would say:
GET /invoices returns all invoices;
A filter can return either paid or due invoices: GET /invoices?state=paid where state can be paid or due.
To mark an invoice as paid, you can either set the corresponding state to your resource, and then you just have to update (replace actually) it using PUT /invoices/<id>.
Alternatively, you can patch your resource: PATCH /invoices/<id>. This method requires a diff like state=paid for example.
It's just a matter of what you want to send to your API (a complete resource, or just the change to apply).
A non-REST solution could be to perform a PATCH request to /invoices/<id>/paid. It's not pure REST but it's ok.