New project: Service Data Format Library

This post is more than 2 years old.

Yesterday while on the road (ok, technically, in the air), I thought it might be kind of cool if there was a "library" of common JSON responses. I've used AJAX mocking services before (hell, I've even built one), but if you don't know the "form" of a remote service, then you can't really mock it, right? To be honest, there probably aren't that many services out there that people need to mock, but if you had an example JSON packet you could use right away, I kinda thought that might be useful.

I've created a new project on GitHub for this: ServiceDataFormatLibrary. It has a grand total of one example so far, but I figured I'd put it out there and see who wants to help flesh it out.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Brian Thornton posted on 4/10/2013 at 5:07 PM

I think passing through level of data depth would be good. I like this..

Comment 2 by Raymond Camden posted on 4/11/2013 at 1:38 AM

Sorry, what?

Comment 3 by Luiz Pereira posted on 4/12/2013 at 4:21 PM

Mr.Camden, I´d like to know your opinion about my article on QR Code dynamic generated content. I´ve sent you an email a couple of days ago, but I got no response, maybe your email client filtered as spam. Thanks in advance. Regards, Luiz Pereira.

Comment 4 by Raymond Camden posted on 4/12/2013 at 4:28 PM

Responded about an hour ago.

Comment 5 by Eric Elliott posted on 4/13/2013 at 3:25 PM

Great idea to gather some mocks for popular services.

I think it would be also be good to get some standard data formats going via HATEOAS / hypermedia API's. A few of us in the community have been working toward standardization of hypermedia types, such as Siren and Collection+JSON.

That way, you won't have to write a bunch of custom code to deal with each different service, and you can get to the business of actually writing your app.

Comment 6 by Raymond Camden posted on 4/13/2013 at 6:28 PM

Eric, I have to admit, I don't know what you are talking about. Can you give me some direction?

Comment 7 by Eric Elliott posted on 4/13/2013 at 7:40 PM

Hypermedia As The Engine Of Application State

"REST APIs must be hypertext driven."

Basically, it's the idea that the API documents itself. When you query it for an object, the response includes enough meta information and links to help you navigate around the API and find related objects, including paging, self links, links to references, possibly a root collection link, and so on.

Using a model like that, it acts a lot more like web pages, which are powerful precisely because they can link. Most current JSON API's do far too little linking, and almost none of them do it in standardized ways.

When we develop hypermedia types that allow us to build a reusable, shareable JavaScript API for interacting with our web services, we'll have made a giant leap forward in API interoperability -- the same kind of leap that was made when hypertext became HTML and made the leap into the browser over HTTP.

Comment 8 by Raymond Camden posted on 4/14/2013 at 12:00 AM

Interesting. I'll be honest and say I don't think I grok this 100% yet. Would this be a practical example?

Given an API that makes use of this, if I requested a list of data, I would know where to find the request details to get the next page of data. As opposed to needing to go read a 'real' doc and code it differently for each service.