I'm trying to understand how to develop and manage microservice using Spring-Boot.
In my situation I'm managing a Restaurant and its Orders, having a List of Products and a order-level DiscountCode. The Products can have their own priced discounted (the owner of the restaurant can set as true the discountedPrice of the product and even let apply the discountcode for the entire order).
The part on what i am struggling on is the following:
How should I manage the validation for the Order? When an order has been created it should check using the other micro-services to make the order completed and valid to be processed.
The steps are:
Order created
Verify the products and its price and if they are discounted as passed by the FE
Verify the existence of the discountCode and apply it to the order
Should I create a different component that receives the order created and validate them asynchronously (using RabbitMQ) and getting the information from the other microservices?
Thanks in advice
That's a difficult question, because we did not knwo the domain and the existing services.
Each service should be responible for its own validation. To check if the discount is valid I would prefer that the Discount-Service should do the validation.
If it is same as the order service, the order service should get back the object and validate it after getting the prices.
But it's up to you and your domain.
Related
I have a doubt about stripe subscriptions when using them with connect accounts.
I want to allow my clients to create subscriptions for a product set up by seller. I have seen how to set up the connect account and the application fee for my business, and here comes my question.
I also offer some extra service that is not related to the merchant so the price of these services should go to my business without any repercusion to the merchant but as far as i have seen the application fee goes to the subscription and not per item.
Maybe i could create 2 subscriptions to achieve this, but if i'm right it will create multiple charges on each billing cycle and same with the invoices.
Is there any way to tie several subscriptions or apply a fee to a specific subscription item?
Thanks a lot in advance
No, what your asking is not supported. Your options are:
Create multiple subscriptions (docs), but as you noted this will involve multiple charges
Set an explicit application_fee_amount on each Invoice that is created, based on your business rules (docs)
Create manual transfers for the correct amount after invoice payment events, similar to "separate charge & transfers" (docs)
Option 3 is fairly advanced, and I would not recommend it unless the first two don't meet your needs.
I need to build a /search API that allows someone to send a POST, and retrieve an ID that can be queried later via a seperate /results API.
I've looked at Spring methods:
DeferredResult
#Async
but neither seem to demonstrate returning an ID from a search. I need to have a system that can remember the ID and reference it when someone calls the /results API to retrieve specific results for a search.
Are there any examples of a Spring application doing this
You must remember that Restful services are stateless, therefore It won't be a good practice keeping your search results states in the server.
One solution could be storing your search states on a Database (SQL/NoSQL) and using the Spring Cache support to improve response times.
When an user requests a new search using /search, on the server you must generate the ID, prepare your results and persist it on the database, then you send the new ID to the client. Later the client must request its results using /results/{searchId}.
Please let me know if you'll use this possible solution and I'll share you an example on Github
I am working on a project which is using micro-services architecture.
There is two services:
UserAPI : all thing related to user come here.
OMS : All things related to Order Come here.
I need to provide orders based on following filter :
By User Id
By Date
By Status
By User Phone Number
mix of above
So i create an API
path/orders?date=12/11/2016&status=delivered&phone=1111111111
Now i need to provide Orders for User by user ID. So which is good rest design:
Add user ID in query param in existing API like path/orders?user_id=1
Create a Separate API path user/{user_id}/orders
Both of your options are OK. But there are different semantics.
path/orders?user_id=1
This is looking up by orders. Orders maybe looked up for example to do some statistical analysis. The orders can be filtered by different parameters, the user id being one of them. For this (when the orders is the main interest) the above URI strategy is fine.
Now on the other hand you may want to look up a user and see their orders. Maybe to do some analysis on their ordering habits. Here you want user information along with their orders. This is where your second URI scheme would be better
user/{user_id}/orders
These are the orders that belong to the user. So it is a relationship. This is where this URI scheme works better.
So really there's nothing wrong with having both options. You just need to follow the semantics of when each should be used.
I am currently new to RESTful Architecture and using Jersey to practice. i am facing difficulty in implementing GET operation.following REST naming/URL convention for getting a particular customer from the server would be
GET http://www.example.com/customers/33245
However while designing client side how would the client know that specific id belong that specific customer as it would be in the database linked with the server and hidden from client. One implementation i think of is to extract all the information regarding all the customers from the database and store in the client but i believe it kills the whole purpose. what should be the optimum way for searching for a specific customer.
Such an URL is used for getting a customer that you already know. Not for searching customers.
For searching customers, you would typically use an URL like
http://www.example.com/customers?name=Doe&firstname=John
This would list all the customers named John Doe, and the list would contain, for every customer, the ID of the found customer. The client would then use this ID to invoke the URL in your question and get detailed information about this customer.
You can of course use any query criteria you want, or allow accessing customers by other means.
If you think about it, that's exactly how web searchingworks. You don't know the URL of a page, you search for this page by keywords on Google, which returns a list of results containing the title, description and URL of thepage, then you use the URL to actually access the page.
I am creating an app store for digital services. I want the user to be able to choose multiple products with different quantity before confirming the order and pay for the services. This requires that something keep state. From REST Wikipedia:
Each request from any client contains all the information necessary to service the request, and session state is held in the client.
I got state that I need to keep somewhere, and I also have a flow. The flow I can mange, but it is the state that I don't understand how and where I should store. The user may add several products to a shopping cart before checking out.
I have thought of a endpoint like this where you post a cart-item object each time you want something.
POST /shopping-cart
But I shouldn't use HTTP sessions if I understand it right? I have seen someone saying to store it in database but would you use a in memory database then? When should i flush the database if the user doesn't confirm and pay? I could need some input on what I should do to keep it simple and RESTful.
I am using Spring 4.x and Java EE for the record.
But I shouldn't use HTTP sessions if I understand it right?
Correct.
I have seen someone saying to store it in database but would you use a in memory database then?
You should keep in in a disk-storage database. This allows you to add nodes to your server without having to worry about routing all requests from one client to the same node.
When should i flush the database if the user doesn't confirm and pay?
That's a business decision.