1

I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.

What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.

When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?

What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?

Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?

Sam Levin
  • 3,326
  • 7
  • 30
  • 44
  • This is pretty broad. Do you have an integration environment, available with an actual FQDN, that your API is deployed to? If not, I would recommend looking into that - this is precisely what an integration environment is for in testing. – admdrew Aug 04 '14 at 20:10
  • It's true, and I do - although it's not quite ready yet. I just wanted to do a little leg-work beforehand – Sam Levin Aug 04 '14 at 20:12

2 Answers2

1

This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.

If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:

  1. Respond with appropriate headers that allow for techniques like CORS to work.
  2. Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
  3. Use JSONP or other techniques.

If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
  • Thank you. This is what I was looking for, and didn't seem too broad. Do you think that performancewise, adding approved domains in the response header (or wherever it goes) via the web server is better than doing it through the language that my app is written in? – Sam Levin Aug 05 '14 at 01:03
  • I would bet that the performance difference would be negligible. A more important concern would be for you to decide where it would be best suited for your needs. If it's in your code then you can switch web server technology without worry, but it might be harder for a DevOps to reconfigure its behavior by forcing a recompilation of the app code to change it. – Brian Kelly Aug 05 '14 at 01:31
0

When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?

You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?

Community
  • 1
  • 1
Catfish
  • 18,876
  • 54
  • 209
  • 353