Would like a sample update basket item API request

[jtlapp]

Hey Robert. After reviewing the dev docs on the API, my confidence that I understand how to issue a request to update a basket item is hovering around 5%. My confidence is at 95% that I'll be spending hours performing random experiments trying to guess unexplained bits.

Can you ask the developers for an example of a request to update a basket item? I believe the following is the service that we would use:

https://developer.spreadshirt.net/display/API/Basket+Resources#BasketResources-UpdateBasketItem

Is there a way to issue a JSON payload? Despite being one of the people who helped create numerous XML standards, I despise XML. It is way too complex. A technology should not try to be anything to anyone, as XML does. (We argued for a simplified RPC specification but got no traction.)

I'm looking for headers and payload. It would be even more helpful if they could map data from the basket in local storage to the elements in the payload. For example, there are three product IDs for each basket item: id, productId, and apiProductId.

Thanks for your help!

[RobertSpread]

Usually spreadshirt support json via the mediaType=json parameter when pulling data. When posting data you could set the content type to "json" to post json to the API. I have a request pending to get more details from the devs./

[jtlapp]

Awesome. Thank you! I'm trying to launch my store at 8:15am CST before the holiday. I have encountered some crazy stuff. I suspect I may be one of the first to try to distribute one store across many pages of a third-party site.

[RobertSpread]

So, apparently there is no documentation o the JSON. (or they do not want to give it to me ;)) The statement was, that a simple XML to JSON translation should be sufficient as both follow the same requirements. I once wrote a plugin to add products to the basket. I have this on my home laptop and will provide a code snipped tonight.

[jtlapp]

Awesome. Thank you! I wonder if one issue is that when you get your basket data from the API, you know exactly what to send back. But we're getting it from a different local data structure, with different identifiers.

[RobertSpread]

The structure of the API and the localStorage unfortunately have nothing in common :(

[RobertSpread]

Here is the representation of an basket item addition to an existing basket in XML:

basket2.txt

Here is a whole working example I am using in one of my many outdated projects: basket.txt

Since we have the productID, the sizeID, the appearanceID and the quantity it should be quite easy to implement. I will try to get this done in the php proxy during this week but am not sure I can achieve this based on the current workload. Precondition is, that you have a basketId (the apiBasketId in our case and should always be available as we want to update a basket) and that you post to this basket using the basketURL/items ressource.

I hope it helps a little. Cheers Robert

[jtlapp]

Ooo. Good stuff. Thanks! Is the reason that you didn't have spreadCart read the basket from the API because the basket was already in local storage? I realize that spreadCart would have to get the basket ID locally regardless.

[RobertSpread]

The original idea was to have something that does not necessarily need php/node.js. (Deletion was initially not planned ;) ). Therefore using the local storage to only read was the simplest possible solution since there is just some JSON parsing and no API knowledge needed. What do you mean with: "I realize that spreadCart would have to get the basket ID locally regardless.".

Cheers Robert

[jtlapp]

I'm thinking that we should require that people delete items via the delete icon/link and restrict item quantities >= 1. That is, if we had +/- buttons to change an item's quantity, the - button would disable when the quantity is 1. If we allow the decrement button to delete the item, I think we would then need to show a dialog confirming deletion. Keeping deletion a separate button should eliminate the need for a confirmation dialog, provided that we space the delete button away from the +/- buttons.

I'd also like to give people the ability to type the new quantity, but again disallowing a quantity of zero. Typing allows users to quickly set large quantities. Allowing a zero quantity creates the strange situation of needing to delete a cart item upon the user entering text into the item. I think allowing zero quantities work better when we have an explicit "update" button, which I don't think we need.

It seems that there are three times available to us for issuing updates to the API:

(a) Issue an update every time the user increments or decrements a quantity, and every time an onchange event occurs for a text value. This can potentially result in numerous calls to the API.

(b) Issue an update to the API only when the user leaves the shopping cart. We can minimize the number of API calls this way, but we potentially introduce situations where changes don't get saved. For example, will we be able to save changes when the user hits the back button? We won't be able to save changes if power goes out to the computer, but that may not be much of an issue.

(c) Periodically issue shopping cart updates to the API while the user is making changes in the cart. The updates would be done on a timer basis. This largely addresses the issues of (b), but still requires saving changes to the API when the user closes the shopping cart.

It looks like approach (a) is the simplest.

[RobertSpread]

I added a new branch for adding/deleting items so we have a clean master. I implemented (in PHP) the option to make everything 100items. It works and hopefully helps you for the node.js side. For now you just have one button that set's everything to 100. I did no proper implementation on the user interface or anything else so far.

[RobertSpread]

Btw. we can go for an input field to define the quantity. we also can go for the +/- pattern. We just have do do the interface ;) Sorry that it took me that long. As said, no developer, just a friend of solutions. Therefore it usually takes a little longer for me.

[jtlapp]

Excellent. Thank you very much! This will be really helpful. Do you know where the api key is coming from? I don't see it in the local basket data. Will I need to get an API key?

[RobertSpread]

The api key is needed accordingly to the documentation but it works w/o in reality.

[jtlapp]

That might be because the browser needs to be able to access the shopping cart. It's not just a function for servers.

[jtlapp]

You wrote: What do you mean with: "I realize that spreadCart would have to get the basket ID locally regardless."

Aren't we relying on SpreadShop to provide the shopping cart basket ID? We need to get our hands on their ID so we can report the same shopping cart. If we can use the APIs to get everything about this cart from this ID, we might be able to remove dependencies on unpublished APIs -- except for however it is that we get the basket ID.

[RobertSpread]

Yes we do rely on providin the cart basketID. For everything else we could use the api directly. It would be actually quite simple but tedious to do this.I would suggest to merge the addition/deletion of items to the master as soon as we both are happy with the implementation and afterwards we can open up a branch remove more dependencies.

[jtlapp]

Hey Robert. I'm having to spend the week catching up on things I neglected rushing to get my Spreadshirt shop up. I'll try returning to things next week. Thanks for all your help!

[RobertSpread]

Catch up with what ever you need. I am still so impressed and overwhelmed by your support that you stepping back for a week is no issue at all.