REST API - Reduce number of POSTS operations - api

I have designed some API which have some nested resources and I am wondering how to reduce the number of POSTS when I am creating some records.
for example, I have the following resources:
/orders/
and
/orders/{order_id}/products/
at the moment I need to run two POST separately if I need to create a new order or a new order's product but I would like to reduce the time for this and run only one POST.
Is this possible? is there any documentation I can read about this?
Thank you

Although you might have found your answer in an other thread there is still some issue regarding your endpoint design.
The first intuition that your endpoint give is that product resource could exist in several place.
./orders/{order_id}/products/{prod_id}
./products/{prod_id}
The question you should ask yourself is: Do you really want to refer to product?
Can product be leaving outside of any orders?
Having a resource sitting in 2 different place might not be that great as you are managing 2 different endpoint with similar behavior. Keeping consistency between both endpoint is not that easy.
My 2 cent is to avoid the term product as it can be confused with a single instance of a product. For example if you sell a toothbrush branded AAA, sku 1234 an order is not compose by this product but by one off the item that you have in stock. The item is "instance" of the toothbrush branded AAA, sku 1234.
As I understand your question you are not really referring to a product but more to a stock-item which should be a unique id.
The resource stock-item if you decide to have one should exist prior to the order. I guess the customer is not adding item to your stock and at the same time purchasing this item.
In conclusion I think that you are not creating the stock-item resource at all when creating orders but just making a reference to it.

Related

VirtoCommerce API getting item prices

I am using VirtoCommerce 2.9 and have some questions regarding the API and what would be the best way to get all the information I need, while keeping the number of API requests down.
Right now I am using the endpoint /api/catalog/search to find items that matches a number of attributes. But the response does not include prices and product texts. Both I would like to present to the end user. What would be the correct or best way to retrieve this information?
Thanks!
Cheers!
Currently search service does not return the description and price for the products.
To get this details you need to use separate queries
api/catalog/product/ids?respGroup='ItemSmall'
to get product detail with description and
api/pricing/evaluate
to retrieve actual products prices. You can call them in parallel for better performance.
Be aware to use WithProperties response group because it may cause
perfomance problem. Anyway product returned with all properties values
and this 'response group' is only responsible for retrieving properties meta-information
(as possible dictionary values, multilingual, required or optional flag etc) this information often used in admin area and in storefront almost not used.
Indexed search module will be serious changed in future versions, and you will be able to have more control over the product details in the search index.

eBay API RelistFixedPriceItem vs AddFixedPriceItem when updating quantity

I am building a system that publishes products from our inventory to our eBay seller account. Everything is working fine, but I just keep thinking which call should I use when I update the quantity in our inventory.
RelistFixedPriceItem and AddFixedPriceItem both are working well, except that on eBay I will have same item with two different itemID, one is sold and one is active...
is that ok? Does it have something to do with eBay listing terms?
Any Advice?
Thanks
AddFixedPriceItem creates a new listing that does not include any data regarding the previous listing's statistics or sales data. RelistFixedPriceItem will create a listing for the product that does include the sales data from the original listing.
The eBay best match search engine uses a listing's sales stats as part of its algorithm to determine search standing. So if your original listing had a good number of views or sales, I would definitely recommend using ReslistFixedPriceItem. However, if your previous listings was stagnant for a long time without many views or sales, it might be more advantageous to use AddFixedPriceItem instead to give the listing a clean slate.
eBay is always changing their search algorithms, so there is no hard and fast rule here. You really just have to find out what works best for your particular products. Experimentation is key.

Ebay API - How to get an item's ancestor/root category?

I'm retrieving the item info of many items using getMultipleItems in the Shopping API, and I need to find-out the items' root category. In the US site (0), the root categories are here: http://www.isoldwhat.com/getcats/fullcategorytree.php
How can I tell which of these an item belongs to (for example, "Computers/Tablets & Networking")? Can I do it within getMultipleItems (or getSingleItem) or do I need another call?
It seems like a short question, but this problem is shared with my use of the Amazon API to which I've been doing extensive research and I decided to resolve it on my eBay end. The "problem" is determining the selling fee, which can be done on Amazon's side, by getting the ProductGroup of the item, or by using eBay's root categories, and matching either one to the fee table Amazon defined for it's commission rates. In this case, there's not a lot of turn-out to refer to here to show I looked everything up.
The getCategoryInfo and related category-info-searching doesn't pertain to particular items. I get a <primarycategoryid> N/V pair in my item responses, but (I'm pretty sure) that's a leaf category (mapping 10,000+ leaf categories [even just the fraction I would use] to Amazon's product group-specific fee table would be a hell of a pain).
Again, how do I trace an <item> to it's ancestor/root category?
You can trace the root of a category via the PrimaryCategoryIDPath field that is returned when calling GetMultipleItems.
Keep in mind that this information is not returned unless you have specified Details in the IncludeSelector field as part of your request.
More information on PrimaryCategoryIDPath can be found here.

Vendor specific pricing on Shopify

A client of mine has a service-oriented ecommerce site on Shopify and he's asked me to assist in making a few changes. I've never utilized the service so I'm not really familiar with it.
The price list was static at first since the client used the same vendor however now that they're growing - and therefore using multiple vendors - the costs are fluctuating and therefore the prices on Shopify need to reflect that.
I need to set it up so that when a customer logs on a vendor is programmatically chosen based on their geographic location and the prices (shown to the customer) adjust accordingly.
Is this possible? And if so, what objects/API docs should I be looking at. I seems as if I can easily hard code this with IF statements but I'd like this to scale cleanly so I'm looking for a more efficient solution.
I think this should be possible. Based on your comment:
Will I not have a zip code for the customer? – RyanMac
The easiest way would be to create a Product Variant for each region. Based on the customer.default_address you could find the customers ZIP code. Next step would be to use this within the product.liquid template to select the correct variant.
The biggest problem you have is determining their location. When a customer logs in, you know who they are, so you could dish out only products of interest to them. Problem is, how do you lump people into those regions? You have your work cut out there. When you create a customer you can assign them any code you want, so perhaps you could just match customers to vendors using a match on that. Lump any customers into GroupA and you show only products with Vendor GroupA, any customers assigned to GroupB render products from vendor GroupB....etc

"Dynamic" Pricing System

Soon I'll be working on a project that amounts to what is essentially an e-commerce app for configured products. This question is about ways to implement pricing schemes that can change from day to day, so we want to get the pricing logic out of code and into a database, but not in a way that causes the database to do all the work.
The basic idea is this, there are 5 attributes. You pick an option from each of those attributes. Then you start adding products to your cart. All the product you add will have those 5 attributes tacked onto them (the attributes will affect the pricing). Once you've added a product, you can apply modifications to it (the attributes will also be applied to the modifications).
So, what we've got at this point is a product (which has a fixed base price) with some information about it (that will modify the price), and zero or more modifications (which has a fixed price) and some information about them (which will modify the price). Modifications can also incur additional charges. For instance, if company A uses this software and they price their items using: BASE_PRICE + $50 * NUM_WHIRLIGIGS and the item has a modification that adds a WHIRLIGIG, that will have to be reflected in the price.
Do you know of any examples of different pricing systems that I might find useful when determining how to set this up? Do you have better ideas?
My current best thought is below, you can skip it if you're not curious about the particulars of the method and just want to get right to the answering!
For any given item (or collection of items) the company could use a special interface to set up pricing formulas which would then be interpreted and evaluated at run-time.
So for PRODUCT_A, the company might put in something like BASE_PRICE + WHIRLIGIG_UPCHARGE * NUM_WHIRLIGIGS. And the software, when it comes time to price it, would look at how many WHIRLIGIGS the item has, as well as how many WHIRLIGIGS are added by any modifications.
Does anyone have experience implementing this kind of interpreter? How did it turn out? Was it difficult/troublesome?
Thanks in advance for all the awesome input I'll sure I'll get. :P
Typically, this is usually handled with product bundles which have components. So a product with 5 additional subcomponents would not be base + 5 * addon, but SUM(base, addon, addon, addon, addon, addon).
So your product table may either be self-referential or there is some kind of link table which says which sub-products are allowed to be attached to which products.
In my experience, pricing is usually stored on a product/customer or contract basis, so that's another table.
Then the actual orders themselves contain product bundles. If the order is a quote, then the pricing is frozen (up to the expiration of the quote).
When an quote or order is turned into an invoice, at that time the pricing is either locked in from the main pricing or the quote, depending upon the pricing timing paradigm.