I have a collection of Employees, on which CRUD operations can be performed.
I am working on 2 given endpoints
delete multiple employees in single API requests given the ids of the employees to be deleted is given in the body of the request.
update multiple employees using single API request.
Lets consider an example where one of the ID is not found in the list of employee ids to be deleted/deleted/updated, in this case should the whole request be rejected ? or delete the existing ones and send error response only for the not found id?
It would be helpful, if you could help me with the best practice.
Thank you,
KK
Related
Hello I have a question about choreography,
I know it's asynchronous, but in this context:
a requisition in endPoint / addEmployee (where to create an employee the existence in the department is necessary), I would check for an employee and send a message in my department queue to verify the existence and also sign up in the queue to hear the answer, would that be choreography?
Or when confirming the existence of the employee, should I create and send the response already? or can i send the response after consuming the departament queue?
Or in this case, would the orchestration be correct?
If I understand correctly you are receiving a request or a message which contains information to create an employee. One of those field is department name or id. And you would like to validate existence of this department information from department service. Is my understanding correct? If so I would say a lot easier solution would be keeping a basic department data on your employee service. You can get department created, updated events from department service and sync your data instead of asking for each and every employee.
With this solution you wont have a dependency between services. You will just listen the topic or queue to which you wont know where the message comes from which is total opposite of the coupling.
I tried calling DocuSign sales and support (transferred around 3 times) and no one could give me a straight answer on this. Their "support" actually told be to try stackoverflow, so here I am...
I'm looking at their API pricing levels here: https://www.docusign.com/products-and-pricing/api-plans-b
If I have the Intermediate API, can I make the following API requests?
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/form_data
The part that's throwing me for a loop is the DocuSign Connect feature in the Advanced API plan. The description of it is:
The DocuSign Connect module lets you configure webhooks for envelope events and recipient actions for some or all users in your account. It can also be used to transport the completed documents back to your app or website and to retrieve any form field data entered by your recipients.
I don't need the webhooks, but I need to be able to get the completed documents as PDFs and get the form field data. Do I really need the DocuSign Connect feature for that?
You will be fine with the intermediate plan. Here is the basic distinction between polling and Connect - With Connect, we will proactively notify YOU when key envelope events occur.
Otherwise, it's up to you to call GET /envelopes and/or GET /form_data to retrieve that information. Be wary of the resource limits when you poll.
As a quick aside, instead of making two requests to retrive that information, just make one - GET /envelopes?include=recipients,tabs. This will provide you all the information you seek in one request.
The important excerpt from that guide:
You may not exceed one GET request per unique envelope endpoint per 15
minutes. If you exceed this limit the request will not fail, but it
will be flagged as a violation of rate limits which can cause your app
to fail review to go-live review.
For example, the following transactions violate API rules due to the repeated GET requests to the first document and second recipient:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:02:00] GET /accounts/12345/envelopes/AAA/recipients/2
[12:03:00] POST /accounts/12345/envelopes
[12:04:00] GET /accounts/12345/envelopes/AAA/documents/1 *
[12:05:00] GET /accounts/12345/envelopes/AAA/recipients/2 *
However, the following set of requests comply with API rules and limits and would not be flagged by the platform:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA
[12:16:00] GET /accounts/12345/envelopes/AAA
[12:17:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:32:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:40:00] PUT /accounts/12345/envelopes/AAA/recipients/1
[12:41:00] PUT /accounts/12345/envelopes/AAA/recipients/1
I'm trying to reduce the api calls to fetch data out of powerbi rest api. when i call endpoint like /Groups, The response is straight forward in a single api call, I get all the groups. in order to get datasets,dashboards and reports i'll have to pass every group id to endpoints of reports,datasets.,etc.
eg.
GET https://api.powerbi.com/v1.0/myorg/groups/{groupId}/datasets
Is there a way to combine these requests, such a way that i send multiple group ids in a single api call to get all the datasets from their respective groups?
I have not found a way to combine it all together to make a single batch api call.
However, I tried a different endpoint found from MSDocs to avoid input of group id.
GET https://api.powerbi.com/v1.0/myorg/datasets
But the problem with this is, the response wont have information of which group the dataset belongs to. without group information,the retrieved data wont be useful for me.
https://learn.microsoft.com/en-us/rest/api/power-bi/datasets
You must use the admin part of the API. To get a list of all groups in your organization, call GetGroupsAsAdmin (you can filter what you want to get too). Similarly, call GetDatasetsAsAdmin to get list of datasets. Look at their webUrl property to find their group.
https://api.powerbi.com/v1.0/myorg/datasets wont return all datasets (or datasets from multiple groups) but will give you the datasets located in your own My workspace.
English is not my native language and i don't understand difference between query and request.
What is the difference between words and how to use them correctly on the web
Request means ask for something and it shall be given. You need that thing.
Query means ask whether or not something is true/ available or false/not available, you may not get that thing back but you'll get the status, state or info.
Request means ask to collect that object.
Query means ask to confirm the state of an object ex. Availability, true/false,
Can I have some food to eat? You are requesting for food.
Is that way good? This is a Query:
A request is like when I ask you to go to the supermarket. Here, I’m requesting you to leave your current place, go to the supermarket to bring one or many items and come back. Now, you can go to the supermarket but once you arrive you will ask yourself, what should I bring? In order to make your visit to the supermarket successful, I should give you a list of things that you need to bring or do at the supermarket, give you a description for the items and tell you in which aisle or department you can find them. This list now is representing your query.
So, if your client needs to fetch some data for example from a remote server, you will need to make a request. This request has a type, like ‘GET’ to fetch resources or data back, or ‘POST’ to do an operation like creating a new user account.
For the request to do its job, you have to specify what data or resources you need this request to fetch and where to find it. It’s like what items do you need to buy from the supermarket and from which aisle can you find them. For example, your request can have a query to return a specific user’s data based on his id. But you need to know to whom should you send the request with this query in order to get the user’s data back based on the passed id.
In order to make a request, you need to send it to your backend’s application that you can access using an IP or a domain mapped to it. Something like: “http://www.mywebsite.com”. But to fetch specific type of data, like the user’s data you need to tell your backend application what are you searching for. This is specified by something called the “path”. For example: “http://www.mywebsite.com/users”. The path here is the “/users” part. The query works when you submit to this domain with the path one or more query parameters, like the user’s id. So, you will make a GET request to “http://www.mywebsite.com/users/1234”, where “1234” here is representing the user’s id that you need to fetch its data. It’s like telling you to go to the supermarket named “mywebsite.com”, go to the “users” isle or department and grab the item with the id “1234”.
I hope that I managed to simplify the concepts a little bit for you.
Mohammed's answer above is great and very detailed. In summary:
First of all, query and request can both be nouns and verbs. E.g:
I requested a refund.
We received a request for a refund.
I queried the price.
We received a query about the price.
To request something is to ask for something, an object or a favour etc. A request is a polite demand. To query is to ask about something i.e. you are wanting information. A query is a question.
Also, QUERY is an inquiry(Query and inquiry are synonyms)
They are both requests but the difference is that the QUERY is a precise request. In informatics, if you need information about something you need to send a specific request with precise information.
"I queried information about user account Maxim Pavlov" = "I need to know about this website users. In particular, I need to know if there is any Maxim Pavlov registered on this site".
If you are Arabic, best translations in Arabic would be, request = طلب and query = إستعلام)
I thought about this question and I think the Ahmed's answer is misleading to say the least.
When web developers talk about request, they usually mean request done via HTTP. There are other protocols, but HTTP is certainly the most common. Request tend to be fourfold: get, post, put and delete. A request is almost always associated with an endpoint. A request is more than just ask for something. For instance, a put request is basically either add information or a file stored on a web server or update it. On the other hand, a query, in the language of a web developer, typically means some information he would like to extract from the database where a certain condition needs to be met.
I will give you an example. When building an API, you may have just two endpoints which are mapping to a post request and a get request. When you hit the endpoint associated with the get request, by design it will always return the "current time" which requires no query in a database. Meanwhile, when you hit the endpoint associated with the post request, by design it will always get the leap years between, say, 1900 and 2000 which are all stored in the database and requires a database query to fetch that information back to you.
The Abdullatif's answer is by and large correct though.
I'm having a problem understanding how basic communication between microservices should be made and I haven't been able to find a good solution or standard way to do this in the other questions. Let's use this basic example.
I have an invoice service that return invoices, every invoice will contain information(ids) about the user and the products. If I have a view in which I need to render the invoices for a specific user, I just make a simple request.
let url = "http://my-domain.com/api/v2/invoices"
let params = {userId:1}
request(url,params,(e,r)=>{
const results = r // An array of 1000 invoices for the user 1
});
Now, for this specific view I will need to make another request to get all the details for each product on each invoice.
results.map((invoice)=>{
invoice.items.map((itemId)=>{
const url=`http://my-domain.com/api/v2/products/${itemId}`
request(url,(e,r)=>{
const product = r
//Do something else.....
});
});
});
I know the code example is not perfect but you can see that this will generate a huge number of requests(at least 1000) to the product service and just for 1 user, now imagine if I have 1000 users making this kind of requests.
What is the right way to get the information off all the products without having to make this number of requests in order to avoid performance issues?.
I found some workarounds for this kind of scenarios such as:
Create an API endpoint that accepts a list of IDs in order to make a single request.
Duplicate the information from the Product service within the invoice service and find a way to keep them in sync.
In a microservices architecture are these the right ways to deal with this kind of issues? For me, they look like simple workarounds.
Edit #1: Based on Remus Rusanu response.
As per Remus recommendation, I decided to isolate my services and describe them a little bit better.
As shown in the image above the microservices are now isolated(in specific the Billing-service) and they now are the owners of the data. By using this structure I ensure that Billing-service is able to work even if there are async jobs or even if the other two services are down.
If I need to create a new invoice, I can call the other two microservices(Users, Inventory) synchronously and then update the data on the "cache" tables(Users, Inventory) in my billing service.
Is it also good to assume these "cache" tables are read-only? I assume they are since only the user/inventory services should be able to modify this information to preserve isolation and authority over the information.
You need to isolate the services as so they do not share state/data. The design in your question is a single macroservice split into 3 correlated storage silos. Case in point, you cannot interpret a result form the 'Invoicing' service w/o correlating the data with the 'Products' response(s).
Isolated microservices mean they own their data and they can operate independently. An invoice is complete as returned from the 'Invoices' service. It contains the product names, the customer name, every information on the invoice. All the data came from its own storage. A separate microservice could be 'Inventory', that operates all the product inventories, current stock etc. It would also have its own data, in its own storage. A 'product' can exist in both storage mediums, and there once was logical link between them (when the invoice was created), but the link is severed now. The 'Inventory' microservice can change its products (eg. remove one, add new SKUs etc) w/o affecting the existing Invoices (this is not only a microservice isolation requirement, is also a basic accounting requirement). I'm not going to enter here into details of what is a product 'identity' in real life.
If you find yourself asking questions like you're asking it likely means you do not have microservices. You should think at your microservice boundaries while considering what happens if you replace all communication with async queued based requests (a response can come 6 days later): If the semantics break, the boundary is probably wrong. If the semantics hold, is the right track.
It all depends on the resilience requirements that you have. Do you want your microservice to function when the other microservices are down or not?
The first solution that you presented is the less resilient: if any of the Users or Products microservices goes down, the Invoice microservice would also go down. Is this what you want? On the other hand, this architecture is the simplest. A variation of this architecture is to let the client make the join requests; this leads to a chatty conversation but it has the advantage that the client could replace the missing information with default information when the other microservices are down.
The second solution offers the biggest possible resilience but it's more complex. Having an event-driven architecture helps a lot in this case. In this architecture the microservices act as swimming lanes. A failure in one of the microservices does not propagate to other microservices.