I'm trying to use the API via JSONP - making a request like:
https://partner.api.beatsmusic.com/v1/api/search/federated?callback=beatsCallback&q=cats&client_id=XXXXX
But the response just comes back as pure json - not wrapped in a callback. Are callbacks supported?
Beats Music supports CORS which allows javascript on a page to make requests to another domain, not the domain it originated from. Thus, you do not need to use JSONP and can access the json in a traditional manner.
Related
My VueJS application relies on a Java backend. This Java backend serves all REST endpoints for providing the data.
When a user performs a checkout the backend responds with a redirect url and redirects the user to that URL. This is done simply like that:
window.location.href = redirectUrl;
As soon as the payment process is finished on the external page the payment provider redirects the user to a return_url which in this case is my VueJS front-end. However the external system sends the return_url in a POST request directly to the front-end which cannot be processed in the as there is no endpoint listening.
What would be an approriate way handling this? As far as I know, VueJS doesn't have any possibility accepting POST requests.
TLDR; It is the responsibility of any external payment gateway system or similar system like OAuth/OpenID to redirect to the calling app via simple browser redirects (via HTTP 302 and 303). So, you should ask/configure external payment provider to follow the standard workflow.
In theory, you should never encounter this problem as POST is typically an Ajax request. Imagine you are on external payment page and when the payment succeeds, external JS is making the POST call and hence the payment page should then take responsibility of redirecting to the appropriate page by reading the reponse.
Now, the second possibility is that payment page is using traditional FORM submission via POST method type and giving back response as JSON or equivalent body. In this case, you should have a server side script (on your ui-server) that would listen for this call and then load the front-end application built with Vue.
If your UI is being served by Java back-end, then it should be simple job of having a Servelet or JSP.
I know there are several questions related to this-- but I couldn't find my answer with them. Plus I wanted a bit more clarification.
I am running a rails app locally which makes a jsonp call to a sinatra application which is being used as an API.
When I put this URL in my browser I end up getting the correct response, yet when I make this call through jQuery using $.getJSON I get a forbidden 403 Error. I understand that the $.getJSON is making a jsonp request based on the url having callback=? parameter.
I'm trying to figure out what is causing the 403 Error. Is there some default configuration on the api application that is refusing the request because the script is being requested from an included script tag?
Right now the api request return json data. I assume it's my responsibility to look at the callback parameter and construct a response that actually calls the callback...
so if url was http://myapi.com?callback=blah, then I should be returning something like:
blah({foo: 'bar'})
But I don't know exactly what the 403 is all about. If it's the api server that is returning, then what is it trying to protect against?
here is an example of what the jsonp call looks like:
$.getJSON( 'http://myapi.com?callback=?', {biz: 'buzz'})
I see posts about setting headers for cross origin concerns-- but not sure why this is needed for jsonp request.
You need to add jsonp support to your sinatra api application.
Here is one way of adding jsonp support to your sinatra app
Add rack-contrip gem to your Gemfile
gem 'rack-contrib'
Add following to your config.ru
require 'rack/contrib'
use Rack::JSONP
Restart your sinatra app and start testing jsop from javascript
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.
if I get data from an external website in JSONP form, how do I access the http header response? I have heard this may be difficult but my experience is that everything is possible.
Nope.
This is completely impossible.
The whole point of JSONP is to bypass the same-origin policy by passing a result through executable Javascript code.
Other than JS code generated by the remote server, you cannot get any information.
I am working with Flickr's REST API and it's working fine. By that, I mean I'm making an AJAX call to the Flickr API and getting a JSON object back, parsing the object, etc. etc.
But this raises a question in my mind. If browsers follow the same-origin policy, then how can they make these types of API requests?
This DEMO fiddle is working, but it sends a cross-domain request to the Flickr domain.
How does this cross-domain request work?
The cross-domain request:
$.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?id=" +
id + "&lang=en-us&format=json&jsoncallback=1");
What you need to understand is that, while browsers do enforce the same origin policy (SOP), there are exceptions when SOP is not enforced. For example, if you have an HTML page - you can insert <img> tags that point to images on any domain. Therefore, the SOP doesn't apply here and you are making a cross-origin HTTP GET request for an image.
The demo you linked to works since it uses a mechanism that works in a similar way. The mechanism is called JSONP - http://en.wikipedia.org/wiki/JSONP and I suggest you read the wiki entry and some other blog posts. In essence, JSONP dynamically injects <script> tags to send a request to any domain (the parameters of the request are added as URL query params), since the same origin policy does not apply to <script> tags (as it doesn't apply to <img> tags).
Another way to invoke REST APIs on other domains is to use the cross-origin resource sharing mechanism (CORS) - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing. In essence, this mechanism enables that browsers don't deny cross-origin request, but rather ask the target service if it wants to allow a specific cross-origin request. The target service tells the browser that it wants to allow cross-origin requests by inserting special HTTP headers in responses:
Access-Control-Allow-Origin: http://www.example.com