This project is read-only.
6
Vote

AddToCart

description

As others plan other APIs, I will concentrate on Product/Cart Interaction, starting with addition of a product in the cart. Then complete all CRUD operations on it.
This is because In my project I will use NOP as a backend to handle also products coming "on the fly" from external product sources, (other inventories/catalogs) inserting them in a common NOP cart and proceeding with the order/Payment/shipping pipeline of NOP.

I will follow strictly the original programming style adopted on the project and stay as close as possible to the original code in NOP controller using ShoppingCartService of Nop.Services.Orders.

Should be ready by next week.

comments

wooncherk wrote Sep 5, 2014 at 7:02 PM

I second that! Cart-related methods are very important.

But we also need to make sure users are authenticated to add to cart. We can't have anyone just issue a REST API to add product to other people's cart. That is why this work item is very important.

Anyway, feel free to do a basic version first. We'll add in authentication and authorization as we progress! :)

mellogrand wrote Sep 8, 2014 at 9:57 AM

As i commented about Auth, it has to do with the architecture you are planning.

Just to make things more clear, we can have two approaches.

1) a rich client (javascript with Jquery or AngularJs (my case) interacts via JSOn and REST APIs with a MVC web server application who is in charge to check Identity and Authorizations of end users. When a user asks for a page to the server (a real or a client-side routed page in a SAP style app like we do in Angular) the browser interacts with the server that then interacts with REST services (local or remote) to execute proper actions and gives back resilts to the server who then interacts back with the browser. In this scenario, where the server app acts as a broker of services between browser and other servers, we have two layers of authentication/authorization. The web application is in charge of browsers (end users) and we only need server-to-server authentication APIs used to interact with service providers. This is the way most Web APIs are offered and Used by major sites because defnes a clear separation of responsabilities in security and better control.

2) With a similar advaced client architecture you can also have a intelligent client interacting directly with external APis without passing in your server to authenticate and ask for services. It makes a much lighter stress on your server, but then requires end-to-end athentication/authorization between che client and the external provider of services. For some read-only applications this is great (weather info, stock ticker, many others) but to me, for an e-commerce app can be risky.

Of course both approaches should be supported, but the first one probably is what most people might want and live well with, without getting in complex security issues. Good anyway to work also on this issue.

Please, comment on this, it is important to have a good understanding of architectural requirements.
bye

sergio