In a recent interview, I was asked, do you know the concept of idempotency in APIs.
I had read it once but I couldn't recall it, felt dumb a bit, so I went back and I read all I can about it.
So here's an example, if the API's were not idempotent would have happened,
Let's say I want to buy a flight ticket from Ahmedabad to Delhi for 3000 INR. I am paying via my Paytm wallet having 10K balance.
I pressed the pay button but nothing happened so after a few seconds I again tried it and it was successful.
After a minute, I got 2 notifications saying we have booked your flight from Ahmedabad to Delhi and your current balance is 4000 INR, and with that follows a mild heart attack, and a loss of 3000 INR, and what if I was booking a flight from Ahmedabad to USA, ðĩðŠĶdead...(account balance).
But in real life, APIs are idempotent.
Meaning, when you press pay once, it stores your request, when you again retry it, it goes and checks, is it the same request??? If yes, it doesn't process it again and voilaa the payment is only done once.
#interview #api #idempotent #learningandgrowing
I had read it once but I couldn't recall it, felt dumb a bit, so I went back and I read all I can about it.
So here's an example, if the API's were not idempotent would have happened,
Let's say I want to buy a flight ticket from Ahmedabad to Delhi for 3000 INR. I am paying via my Paytm wallet having 10K balance.
I pressed the pay button but nothing happened so after a few seconds I again tried it and it was successful.
After a minute, I got 2 notifications saying we have booked your flight from Ahmedabad to Delhi and your current balance is 4000 INR, and with that follows a mild heart attack, and a loss of 3000 INR, and what if I was booking a flight from Ahmedabad to USA, ðĩðŠĶdead...(account balance).
But in real life, APIs are idempotent.
Meaning, when you press pay once, it stores your request, when you again retry it, it goes and checks, is it the same request??? If yes, it doesn't process it again and voilaa the payment is only done once.
#interview #api #idempotent #learningandgrowing
ð2
Stay ahead of the curve in 2023 by learning GraphQL: the modern, flexible alternative to REST APIs.
As we gear up for another new year, I wanted to share some thoughts on a topic that I think will be crucial for developers in 2023: GraphQL.
If you're not already familiar with GraphQL, it's a query language for your API that allows clients to request exactly the data they need, and nothing more. This means that you can get all the data you need in a single request, rather than having to make multiple API calls to get all the data you need.
But why is this important? Well, for one thing, GraphQL can help improve the performance of your applications. With REST APIs, you often have to make multiple API calls to get all the data you need, which can be slow and resource-intensive.
With GraphQL, you can get all the data you need in a single request, which can greatly improve the performance of your application.
Another reason to learn GraphQL is that it can help improve the flexibility of your API. With REST APIs, you often have to design your API around the needs of your clients. This can be a problem if your clients have very different data needs, as you may have to design multiple endpoints to accommodate them all.
With GraphQL, clients can request exactly the data they need, which makes it much easier to design a flexible API that can accommodate a wide range of client needs.
So if you're a developer looking to stay on top of the latest trends in the field, learning GraphQL is definitely worth considering in 2023.
And if you're not familiar with the difference between REST APIs and GraphQL, the attached illustration should help demystify things for you.
Wishing you a very successful year ahead!
I hope this helps! Let me know if you have any questions or need further clarification.
ð If you like my posts, please follow https://www.linkedin.com/in/aman-raj-6168b616a ðšðļ ðð and hit the ð on my profile to get a notification for all my new posts.
#programming #coding #softwareengineering #api #graphql #developer
As we gear up for another new year, I wanted to share some thoughts on a topic that I think will be crucial for developers in 2023: GraphQL.
If you're not already familiar with GraphQL, it's a query language for your API that allows clients to request exactly the data they need, and nothing more. This means that you can get all the data you need in a single request, rather than having to make multiple API calls to get all the data you need.
But why is this important? Well, for one thing, GraphQL can help improve the performance of your applications. With REST APIs, you often have to make multiple API calls to get all the data you need, which can be slow and resource-intensive.
With GraphQL, you can get all the data you need in a single request, which can greatly improve the performance of your application.
Another reason to learn GraphQL is that it can help improve the flexibility of your API. With REST APIs, you often have to design your API around the needs of your clients. This can be a problem if your clients have very different data needs, as you may have to design multiple endpoints to accommodate them all.
With GraphQL, clients can request exactly the data they need, which makes it much easier to design a flexible API that can accommodate a wide range of client needs.
So if you're a developer looking to stay on top of the latest trends in the field, learning GraphQL is definitely worth considering in 2023.
And if you're not familiar with the difference between REST APIs and GraphQL, the attached illustration should help demystify things for you.
Wishing you a very successful year ahead!
I hope this helps! Let me know if you have any questions or need further clarification.
ð If you like my posts, please follow https://www.linkedin.com/in/aman-raj-6168b616a ðšðļ ðð and hit the ð on my profile to get a notification for all my new posts.
#programming #coding #softwareengineering #api #graphql #developer
ðŠðĩðŪð ðķð ððŋðžðð-ðĒðŋðķðīðķðŧ ðĨðēððžððŋð°ðē ðĶðĩðŪðŋðķðŧðī (ððĒðĨðĶ)?
Browsers use CORS, a method, to prevent websites from requesting data from different URLs. A request from a browser includes an origin header in the request message. The browser allows it if it gets to the server of the exact origin; if not, the browser blocks it.
We can deal with CORS issues on the backend. Cross-origin requests require that the values for origin and ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ in the response headers match and it is set by the server. When you add an origin to the backend code, the CORS middleware only permits this URL to communicate with other origins and utilize it for cross-origin resource requests.
There are two ways to fix CORS issues:
ð. ððžðŧðģðķðīððŋðē ððĩðē ððŪð°ðļðēðŧðą ððž ððđðđðžð ððĒðĨðĶ
Server can let all domains with ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ: *. This actually turns off same-origin policy, which is not recommended. Another option would be only to allow particular domain, which is better option, e.g., ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ: ðĩððð―ð://ððžðšðēðąðžðšðŪðķðŧ.ð°ðžðš.
ðŪ. ðĻððē ðŪ ðĢðŋðžð ð ðĶðēðŋððēðŋ
We can use a proxy server to call external API. It acts as a middleware between client and the server. If server doesn't return proper headers defined by CORS, we can add then in the proxy.
#softwareengineering #programming #api #apidesign
Browsers use CORS, a method, to prevent websites from requesting data from different URLs. A request from a browser includes an origin header in the request message. The browser allows it if it gets to the server of the exact origin; if not, the browser blocks it.
We can deal with CORS issues on the backend. Cross-origin requests require that the values for origin and ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ in the response headers match and it is set by the server. When you add an origin to the backend code, the CORS middleware only permits this URL to communicate with other origins and utilize it for cross-origin resource requests.
There are two ways to fix CORS issues:
ð. ððžðŧðģðķðīððŋðē ððĩðē ððŪð°ðļðēðŧðą ððž ððđðđðžð ððĒðĨðĶ
Server can let all domains with ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ: *. This actually turns off same-origin policy, which is not recommended. Another option would be only to allow particular domain, which is better option, e.g., ðð°ð°ðēðð-ððžðŧððŋðžðđ-ððđðđðžð-ðĒðŋðķðīðķðŧ: ðĩððð―ð://ððžðšðēðąðžðšðŪðķðŧ.ð°ðžðš.
ðŪ. ðĻððē ðŪ ðĢðŋðžð ð ðĶðēðŋððēðŋ
We can use a proxy server to call external API. It acts as a middleware between client and the server. If server doesn't return proper headers defined by CORS, we can add then in the proxy.
#softwareengineering #programming #api #apidesign