I am building the section of my e commerce in Flask where customers can choose one of many shipping services alternatives. Building the options for the SelectField is expensive since I have to query and call different APIs from shipping providers to get quotes. After the POST request is sent and I have a selection from my customer, I would like to avoid having to rebuild all the objects, including the company, service, and price. What would be the best approach in this case? I understand g nor session would serve me in this case, and I would really like to avoid having to write options to the database. Thanks.
Related
So this backend will be consumed by an ad-hoc front end application. But will also be integrated by other systems and we will expose API for them.
When designing the rest I see that there is ONE database table (we call it for table A) that can join many other tables, lets say about 10 to 20 other tables.
Now, my strategy would be to build routes in my backend that will "reason" according to the ad-hoc frontend we have.
So if there is a page in the frontend (let's call this page for page1) that requires to get rows from the table A but also fields from let's say 3 other join tables, then I want to create a route in the backend called maybe "page1" which will return rows from table A and also from the other 3 tables.
This is of course an ordinary way to build a backend. But as it will also be used by other systems then somebody could argue that these systems maybe don't have any need for the route "page1". Their frontend will maybe never build a "page1".
So according to people here, it would better to build the API more agnostically. And instead of creating the route "page1" I should build it according to "hateoas". And if I understand that principle, instead of letting my ad-hoc frontend to request the resource "page1" it would request "pageForTableA". And then, the resource "pageForTableA" should return which are the possible table to be joined.
In this case, for my frontend's page1, I would need to make 4 subsequent request to the server, instead of one like I would like to do if there was a "page1" resource in the backend.
What do you think?
I also see a thirt strategy. I don't know if there is a name for this pattern but it would be this way:
A resource in backend that returns only rows from table A. BUT, the route also takes arguments. And the argument is an array with the name of all the other tables someone want to include.
So if frontend calls:
getTableA(array('tableB', 'tableD', 'tableF'))
Then the resource would include/join the tables B, D and F. In short: API resource let's the frontend decide what it want to get delivered.
Which of these 3 strategies are best do you think? Or there is some more that could be taken in consideration?
You need to architect your API in a way that consumers shouldn't know about how the data is stored in the underlying data store.
Furthermore, if you want to allow consumers to decide which fields you want to project in the response, you could give them using some query string format.
BTW, maybe you should avoid re-inventing the wheel. There's a standard called Open Data (OData) which already defines a lot of things like you already require in your API, and since it has been made by Microsoft, it has deep support on .NET.
Check this tutorial (Create an OData v4 Endpoint Using ASP.NET Web API 2.2) to get more in touch with OData.
I am using the Bigcommerce API to develop a small standalone application for a client. I store product information in a local database anytime I fetch products from Bigcommerce, to reduce latency and network load. However, products can change on Bigcommerce, and while it is acceptable for my application to show mildly outdated information, I will need to update my local cache at some point. My current plan is to do this by storing the original date I requested the product, after which I will need to perform another request to refresh the cache.
My question is, given a list of products (including their Bigcommerce IDs), is there a way to request updates to all of them through a single call to the Products Resource? I can make a request for each individual product by calling:
GET {api}/v2/products/{id}
I can also request all products within an unbroken ID range by calling:
GET {api}/v2/products?min_id={value}&max_id={value}
I am able to successfully call both of the above methods, and I can chain them together in loops to fetch all products. What I want to do is request multiple products with unrelated IDs in a single call. So, something like this:
//THIS IS NOT A REAL METHOD!
GET {api}/v2/products?id[]={value1}&id[]={value2}
Is there any way I can do this? Or is there another approach to solving this that I haven't considered? My main requirements are:
Minimal API requests. My application is small but my client's bigcommerce store is not, and I will be processing tens of thousands of products. I have limited CPU and network resources available, and I simply cannot process that many requests.
Scalable. As I said, my client's store is large, and growing. I need a solution whose overhead scales at a manageable rate with number of products.
Note: my application is a small web application written in PHP running on a Linux shared hosting environment. It is a back of house system which will likely only be used by single user at a time, during standard business hours. I haven't tagged the question with PHP because my question is about the API, which is language agnostic.
One approch can be.
First get all products from BigCommerce using simple products call.
Set some interval time to get updated product list.
You can use min_date_modified and max_date_modified OR min_date_created and max_date_created in products API call to get updated products details.
I've successfully got 3rd party merchant orders posting new orders to my client's BigCommerce store programmatically. I've even got product options posting as part of the order (product->option set-> option relationships are a total cluster).
My client relies heavily on configurable fields. I'm able to pull the definitions of the configurable fields for each product, but can't find a way to POST or update the configurable field values through the API.
Is it possible to manipulate an order's configurable fields through the API?
Got a response from the support team # BigCommerce. Manipulating configurable fields via the API is not currently possible and not currently on the roadmap.
Original reply below:
Unfortunately that is a product limitation with the API, it will not tie to configurable fields on the product. The best you can do is attach that information through a generic text field like 'staff_notes'. Honestly I have not heard of any talk of adding a way to add products with configurable fields to orders via the API. I think this may be because anything that can be done with configurable fields can be done with options and options are what is being pushed for the future. I have noted this feedback down though and will pass it along to our Product Manager for the API. Best case scenario is that it may be seen in a future version of the API which is at least several months away.
I'm working on a store that has two types of products: perishable food and general merchandise. The food must always be shipped overnight via FedEx, and the other merchandise must always be shipped via USPS. If somebody orders products from both categories, they must be shipped separately.
Do you know of an existing module or configuration settings that would allow for this?
If not, it sounds like a custom module would be the other solution. In this case, what is the best approach? I'm thinking it would be splitting the order into a multi-address shipment, using the same address for both but with different shipping methods. Unfortunately I'm not sure how to do this programatically, so any tutorials/samples/resources would be greatly appreciated.
Probably the sanest way to handle this would be to create two orders per product type, each shipping with a different carrier to the same address. This also IMO makes more sense from a stores tracking perspective as you can handle each independently from each other.
To get you on the right track(since Magento is especially cryptic in this part of itself) you should read the Inchoo programmatically create order in Magento post and by the same author Programatically create customer and order in Magento with full blown one page checkout.
Basically as I see this going is:
Get the customer order
Itinerate through each product inside the order and split it up in two arrays for each product type
Create a separate order for each product type and use the different shipping methods for each.
You will probably have to extend a some controllers OR do it the non-standard way and use helper functions for this, the hard parts will be integrating the payment/shipping modules inside your order process. Going this way will have you creating the full checkout process as the one page checkout Magento provides won't really work and is too much pain to get to work because of the way it uses AJAX.
Also another alternative is to hook in to Magento's pre-create order events and create the orders there using already defined order data split it up in two orders, but this is something I never heard or saw implemented at the moment so you'd have to do it "blindfolded" so to speak.
An easier approach would be to use a custom field that defines your product's shipping method, this way you just add that and don't care about custom orders. You just react with that, however tracking will become mostly impossible IMO.
Over-ride the Free Shipping module.
You can setup a sales rule that applies to certain products and makes them 'Free Shipping', leaving the other products to your chosen main shipment provider.
You will need to see how this works, however, the point is that Magento does have something built in to split an order into two shipping categories, albeit only a sales rule on free shipping. But you have source code...
What would be best practice for the following situation. I have an ecommerce store that pulls down inventory levels from a distributor. Should the site, for everytime a user loads a product detail page use the third party API for the most up to date data? Or, should the site using third party APIs and then store that data for a certain amount of time in it's own system and update it periodically?
To me it seems obvious that it should be updated everytime the product detail page is loaded but what about high traffic ecommerce stores? Are completely different solutions used for that case?
In this case I would definitely cache the results from the distributor's site for some period of time, rather than hitting them every time you get a request. However, I would not simply use a blanket 5 minute or 30 minute timeout for all cache entries. Instead, I would use some heuristics. If possible, for instance if your application is written in a language like Python, you could attach a simple script to every product which implements the timeout.
This way, if it is an item that is requested infrequently, or one that has a large amount in stock, you could cache for a longer time.
if product.popularityrating > 8 or product.lastqtyinstock < 20:
cache.expire(productnum)
distributor.checkstock(productnum)
This gives you flexibility that you can call on if you need it. Initially, you can set all the rules to something like:
cache.expireover("3m",productnum)
distributor.checkstock(productnum)
In actual fact, the script would probably not include the checkstock function call because that would be in the main app, but it is included here for context. If python seems too heavyweiaght to include just for this small amount of flexibilty, then have a look at TCL which was specifically designed for this type of job. Both can be embedded easily in C, C++, C# and Java applications.
Actually, there is another solution. Your distributor keeps the product catalog on their servers and gives you access to it via Open Catalog Interface. When a user wants to make an order he gets redirected in-place to the distributor's catalog, chooses items then transfers selection back to your shop.
It is widely used in SRM (Supplier Relationship Management) branch.
It depends on many factors: the traffic to your site, how often the inventory levels change, the business impact of displaing outdated data, how often the supplers allow you to call their API, their API's SLA in terms of availability and performance, and so on.
Once you have these answers, there are of course many possibilities here. For example, for a low-traffic site where getting the inventory right is important, you may want to call the 3rd-party API on every call, but revert to some alternative behavior (such as using cached data) if the API does not respond within a certain timeout.
Sometimes, well-designed APIs will include hints as to the validity period of the data. For example, some REST-over-HTTP APIs support various HTTP Cache control headers that can be used to specify a validity period, or to only retrieve data if it has changed since last request.