Should Your Browser Make Client-Side Web API Calls?
Join the DZone community and get the full member experience.Join For Free
With libraries like jQuery, Angular, and React, most libraries already have the ability to make Web API calls out of the box.
Why is this an issue? Where do I start?
Let's start by defining what CORS is.
What Is CORS?
According to developer.mozilla.org:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use.
This allows you to access images, PDFs...heck, even other web pages to display in your own domain pages. That's what makes the web so...linkable.
Images and similar documents, maybe, but Web APIs?
Nope. Not convinced yet.
Why NOT Use CORS?
It's true the fastest way between two points is a straight line, but not when writing APIs.
I understand eliminating the middleman by not posting back to the server, but there's a problem with that type of thinking.
Cross-site Scripting (XSS) is a big thing lately and this type of code screams "security issue!"
Along with XSS, another issue could be redirects.
These are called unvalidated callbacks and you don't want these either.
If you are a developer and feel this last statement is complete BS, you may want to take a security course. Just sayin'.
Nowadays, it's definitely easier, but some legacy applications I've seen (and even recent ones) have some scary hacks which make my hair even whiter than it currently is.
Yeah, not pretty.
How Do We Solve This?
Most developers don't even think about CORS and just go about their business, but there are some administrators who lock down resources on a server and that's when developers go off the deep end and try to figure out ways around it.
This is what gives us bad practices for accessing resources.
After our review from above, developers have two choices.
- The server (known to you at design-time which, by the way, you don't control) receives the request and returns data (JSON, XML, or even HTML).
Let me be clear about this option: THIS IS NOT AN OPTION!
After reviewing the drawbacks from above, the best approach to use a Web API is to call a familiar face: your own server. You received your HTML page from a trusted source (your server, duh!) so why not just call the server and let the server handle the grunt work?
Let's look at the option on the right side.
- Your server makes the API call instead of the browser making the call.
- Your request makes it to the server (again, a server you don't control) and responds to your request.
Once your server receives the data, you can format it the way you want and return the data to the browser.
Do you know how many issues you can solve by letting your server perform the API calls?
So, yes, Plan B is probably your best bet.
With the rise of Web APIs over the last decade, I can see why developers would want to just "make the call" and be done with it.
What are your thoughts? Have you experienced weird behaviors with CORS in your career? Do you even care? Post your comments below and let's discuss.
Published at DZone with permission of Jonathan Danylko, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
Web Development Checklist
Transactional Outbox Patterns Step by Step With Spring and Kotlin
What to Pay Attention to as Automation Upends the Developer Experience