Designing an API: Is JSON/JSONP an and/or decision?

Programer

Active Member
Reputation
0
Executive Summary: Who knew serving up JSON for a public API was so complicatedly anti-hillbilly?
Our next major phase at BookedIN’s plan for world-except-for-Edmonton-and-certain-parts-of-Winnipeg-domination is underway. That’s the public-facing site which will provide a way for YOU THE PUBLIC to book appointments online at your favorite…ahem…”service providers”. Let me explain our marketing strategy in detail.
Ha ha, I jest of course. That last sentence is the sum-total of what I know about our marketing strategy. I have a hard enough time trying to keep myself entertained through code. (As a general rule, I start with the code reviews.)
To populate the public site, we’re building an API around our appointment manager. And we’ve opted for JSON as the default format mostly because I love the way people pronounce it, accenting both syllables like badly-translated anime.
In this app, we are making two API calls from two different places. When we first load the page for a particular vendor, the server makes a call to retrieve the company details and a list of services. After the page is loaded, jQuery comes along and populates the list of available appointment times. In this way, we get the benefit of SEO being able to see the vendor details and services and a snappy user interface when the user navigates to different dates within a particular vendor page, as outlined on the Google Webmaster Blog (though I didn’t actually discover that link until after we decided on the structure).
In the appointment manager, serving up JSON is pretty simple. Configure the servlet, get the data, convert to JSON (we’re using Jackson), and write it to the response. This is working just fine with the server-side company details call.
For the client-side call, it’s not. Depending on how you configure the AJAX call in jQuery, we get one of the following:

The API call is never made
The call is made but cancelled
The call is made and returns but has no data

All are symptoms of the same issue: cross-domain client calls, which aren’t allowed. I read that it’s for security reasons which, due to my loathing of all things security-related, was enough for me not to read further.
From what I can tell, you can’t make a call to another domain in jQuery (or likely any JavaScript library) and expect to get JSON back.
Here’s an example. Follow this link in your browser: https://github.com/api/v2/json/repos/search/zenboard
You’ll probably get this back:


1: {"repositories":[{"type":"repo","username":"amirci",

2: "url":"https://github.com/amirci/zenboard","watchers":5,"owner":"amirci",

3: "has_wiki":true,"open_issues":0,"score":6.994658,"followers":5,"forks":3,

4: "has_issues":true,"language":"Ruby",

5: "description":"Companion to agile zen to provide extra calculations and functionality",

6: "pushed":"2011/05/18 15:25:54 -0700","fork":false,"size":1348,

7: "created_at":"2010/11/24 17:28:33 -0800","name":"zenboard","has_downloads":true,

8: "private":false,"pushed_at":"2011/05/18 15:25:54 -0700",

9: "created":"2010/11/24 17:28:33 -0800","homepage":""}]}


(Side note: If you’re using AgileZen, the project above, ZenBoard, is an awesome companion for it.)
Now let’s try this in jQuery:


1: function loadProjects( ) {

2: var url= "https://github.com/api/v2/json/repos/search/zenboard";

3: $.ajax({

4: url: url,

5: type: "GET",

6: dataType: "json",

7: success: function(data) {

8: alert( 'moo' );

9: }

10: });

11: }


Throw this into a $( document ).ready call, load it up, and you get nothing. The browser developer tools give you a vague hint of what’s going on:
 
Executive Summary: Who knew serving up JSON for a public API was so complicatedly anti-hillbilly?
Our next major phase at BookedIN’s plan for world-except-for-Edmonton-and-certain-parts-of-Winnipeg-domination is underway. That’s the public-facing site which will provide a way for YOU THE PUBLIC to book appointments online at your favorite…ahem…”service providers”. Let me explain our marketing strategy in detail.
Ha ha, I jest of course. That last sentence is the sum-total of what I know about our marketing strategy. I have a hard enough time trying to keep myself entertained through code. (As a general rule, I start with the code reviews.)
To populate the public site, we’re building an API around our appointment manager. And we’ve opted for JSON as the default format mostly because I love the way people pronounce it, accenting both syllables like badly-translated anime.
In this app, we are making two API calls from two different places. When we first load the page for a particular vendor, the server makes a call to retrieve the company details and a list of services. After the page is loaded, jQuery comes along and populates the list of available appointment times. In this way, we get the benefit of SEO being able to see the vendor details and services and a snappy user interface when the user navigates to different dates within a particular vendor page, as outlined on the Google Webmaster Blog (though I didn’t actually discover that link until after we decided on the structure).
In the appointment manager, serving up JSON is pretty simple. Configure the servlet, get the data, convert to JSON (we’re using Jackson), and write it to the response. This is working just fine with the server-side company details call.
For the client-side call, it’s not. Depending on how you configure the AJAX call in jQuery, we get one of the following:

The API call is never made
The call is made but cancelled
The call is made and returns but has no data

All are symptoms of the same issue: cross-domain client calls, which aren’t allowed. I read that it’s for security reasons which, due to my loathing of all things security-related, was enough for me not to read further.
From what I can tell, you can’t make a call to another domain in jQuery (or likely any JavaScript library) and expect to get JSON back.
Here’s an example. Follow this link in your browser: https://github.com/api/v2/json/repos/search/zenboard
You’ll probably get this back:


1: {"repositories":[{"type":"repo","username":"amirci",

2: "url":"https://github.com/amirci/zenboard","watchers":5,"owner":"amirci",

3: "has_wiki":true,"open_issues":0,"score":6.994658,"followers":5,"forks":3,

4: "has_issues":true,"language":"Ruby",

5: "description":"Companion to agile zen to provide extra calculations and functionality",

6: "pushed":"2011/05/18 15:25:54 -0700","fork":false,"size":1348,

7: "created_at":"2010/11/24 17:28:33 -0800","name":"zenboard","has_downloads":true,

8: "private":false,"pushed_at":"2011/05/18 15:25:54 -0700",

9: "created":"2010/11/24 17:28:33 -0800","homepage":""}]}


(Side note: If you’re using AgileZen, the project above, ZenBoard, is an awesome companion for it.)
Now let’s try this in jQuery:


1: function loadProjects( ) {

2: var url= "https://github.com/api/v2/json/repos/search/zenboard";

3: $.ajax({

4: url: url,

5: type: "GET",

6: dataType: "json",

7: success: function(data) {

8: alert( 'moo' );

9: }

10: });

11: }


Throw this into a $( document ).ready call, load it up, and you get nothing. The browser developer tools give you a vague hint of what’s going on:
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…