Implementation Language

[Doug Swanson]

New to the group and really loving the discussion of ideas.

Hope this isn't "out of bounds" to ask but I'm curious to know more
detail about what specific implementation environments people are
using - language choice etc.

We're looking at building a RESTful API, leaning toward Java (looking
deeper at JAX-RS implementations) and started wondering what we could
learn from what others are up to.

[Sam Ramji]

Welcome!

There are no out-of-bounds questions about APIs here.

I've personally seen a lot of APIs built in Java; more people are talking about Scala these days. 

The pairing data technology is also really important; Oracle is not a great choice for an API backing store, but MongoDB, Riak, and Cassandra seem to be delivering well.

Cheers,

Sam

[Doug Swanson]

Appreciate the quick response!

As far as Java goes any thoughts on JAX-RS implementations (i.e.
Jersey, Restlet, Spring, etc)?

Can you expand on why you say Oracle (and I'm assuming SQL databases
in general) are not as good a fit?

[Jack Repenning]

On Feb 16, 2012, at 2:47 PM, Doug Swanson wrote:

> curious to know more
> detail about what specific implementation environments people are
> using

Ruby On Rails, with MySQL back end, NGinX front end.

Jack Repenning

[Jeff Schmidt]

Java 6, Spring, Spring Security/OAuth, Spring Integration, JAX-RS (via
Jersey), Apache Cassandra (via Hector/Hector Object Mapper), and Solr
(via SolrJ) and ehcache.

Been working with a Java shop for quite some time, but still managed
to use a fair amount of Groovy for content extraction for creating
files to be indexed by Solr or loaded into Cassandra. Scala sounds
very interesting to me as well. Hey, JVM based languages open
doors. :) I understand Lift is not necessarily oriented to providing
APIs so much as actual UIs.

Jeff

[Roy Wilson]

Jack,

Your menu is, compared to the others (esp twitter and engineyard), is
rather sparse. Is this because, in part, you are less concerned about
high levels of chatty mobile driven traffic? If not, what makes your
lineup so parsimonious?

Roy

--
Roy Wilson
email: anw...@gmail.com

[Jack Repenning]

On Feb 16, 2012, at 3:54 PM, Roy Wilson wrote:

> Your menu is, compared to the others (esp twitter and engineyard), is
> rather sparse. Is this because, in part, you are less concerned about
> high levels of chatty mobile driven traffic? If not, what makes your
> lineup so parsimonious?

Yes: my API is very low bandwidth. It's not an end-user API at all, but a B-to-B, negotiated partnership thing.

Jack Repenning

[Roy Wilson]

Oh, right. You mentioned that before. Thx.

On 2/16/12, Jack Repenning <repenni...@gmail.com> wrote:
>

[Sam Ramji]

We've seen that a lot of API data, even dynamic data that changes "a lot" like Twitter, is read-mostly and very cacheable, plus requires availability and performance in order to scale to meet client demand.

Oracle focuses on the Consistency side of CAP and to get the Availability it's extremely expensive (our customers have quoted "millions of dollars for software"). It is a fine fit for back-end systems of record (SOR) and internal application development that requires SPROCs and perfect consistency.  You may have API calls that tunnel back to an Oracle system on write.  It just doesn't make sense to have this Mercedes-class infrastructure as your default API server layer.

For JAX-RS, Jersey seems to be the trend these days from what I can see, and Jackson (http://jackson.codehaus.org/) is getting a lot of use and attention.

Cheers,

Sam

[Ed Anuff]

I certainly would certainly agree with most of the ones Jeff lists as being the best choices if you're a Java (or JVM language) shop.  Jersey is really a great JAX-RS implementation and has a large community working with it.  I think Apache Shiro is worth a look for security, tends to be more lightweight than Spring Security and somewhat easier to adapt if your security model isn't exactly the same as Spring Security assumes.  Apache Amber for OAuth has had a lot of starts and stops but still looks very promising if they can get to a 1.0 release.  Cassandra with Hector is hard to beat if you've got the dataset that warrants it.

Ed

[Jeff Schmidt]

I just searched around my email a bit, and found if you're looking to
implement APIs using Scala, check out BlueEyes (https://github.com/
jdegoes/blueeyes). Maybe the next project. :)

Jeff

[Ross Mason]

We do a lot of B2B API work in Java and from what we've found Jersey is one
of the best JAX-RS implementations out there and Jackson provides a much
needed boost to JSON processing in Java.

For backend storage we prefer Mongo or similar.  For our platform we went
with Jersey, Jackson, Mongo and pretty happy with it.

Cheers,

Ross Mason
CTO, Founder
MuleSoft Inc.

@rossmason

Try iON: integration Platform as a Service http://muleion.com

http://mulesoft.com | http://blogs.mulesoft.org

[Chris O'Dell]

I think I'm going to break the trend here, but we're using a full .Net stack written in C# and using OpenRasta as the framework. 

[Kevin Swiber]

On Thursday, February 16, 2012, Doug Swanson <dswan...@gmail.com> wrote:
>
> Hope this isn't "out of bounds" to ask but I'm curious to know more
> detail about what specific implementation environments people are
> using - language choice etc.

I'm currently working on a couple of Web API's (hypermedia based) using Node.js, which has so far been a really great experience. We're using MongoDB on the back end. We will soon be moving from Amazon Linux to Ubuntu EC2 instances.

Some of the benefits: JSON objects all the way through, from the database through the app server to client. Fast development time with Node.js and the module ecosystem. Node.js and MongoDB both offer low friction development with big scaling opportunity.

(Note: we are still in development, so I can't speak to real world longevity in the wild, but I think the technology helps to put us in a good spot for growth.)

--
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[Darrel Miller]

C#, .Net and SQL Server as the primary API to an ERP application.
Fully hypermedia driven, with approx 1000 distinct URI templates using
a few custom designed media types. Drives desktop, browser and touch
clients.

Darrel

[Sam Ramji]

I can't wait to hear how this architecture turns out in production.

I'm seeing a ton of Node.js adoption and it looks like implementations are getting more and more solid.  The JSON-all-the-way-through benefits look really interesting.

Tom Hughes-Croucher (ex-Yahoo! and Joyent) is doing solid work on this stuff in real-life/production - you can find him at http://jetpacks4dinosaurs.com and @sh1mmer if you need.

Cheers,

Sam

[Kevin Swiber]

Sam, thanks for the info!  I'll follow Tom and see if he's interested in some design discussion around this architecture.

There are a lot of benefits to the JSON-all-the-way-through approach.  It makes saving use case specific read models a snap, for instance.

I'll start putting together a list of pros and cons as we go through the development / beta / launch process.

Also, if anyone's interested in Node.js and happens to live in the Detroit area, there's a Node.js Meetup we hold once a month.  I'd love to get together and chat.  You can find us at http://www.meetup.com/DetNode/.

I'm also interested in chatting with anyone else who's looking to stand up similar architectures.  Feel free to hit me up on Twitter!

Thanks.

[Michael Rose]

Groovy + Grails is a great way to get an API off the ground -- doesn't
scale too badly either, especially with Servlet 3.0 features in Grails
2.0. Our favorite part of Groovy is the ability to mix and match Java
libraries as well as writing in Java for performance-critical code.
Groovy also has Groovy++ which does static compiliation and
optimization of Groovy.

We use Grails extensively for the http://fullcontact.com API, though
as scale starts to really become an issue we've been looking at moving
off it to a Finagle-esque architecture. In general, our frontend API
servers are rock-solid with good response times. :)

Our developer evangelist pointed me at this group, I can see there's
much to learn and share here.

---
Michael Rose (@Xorlev)
Senior Backend Engineer
FullContact Inc.

On Feb 17, 9:01 am, Kevin Swiber <kswi...@gmail.com> wrote:
> Sam, thanks for the info!  I'll follow Tom and see if he's interested in
> some design discussion around this architecture.
>
> There are a lot of benefits to the JSON-all-the-way-through approach.  It
> makes saving use case specific read models a snap, for instance.
>
> I'll start putting together a list of pros and cons as we go through the
> development / beta / launch process.
>
> Also, if anyone's interested in Node.js and happens to live in the Detroit
> area, there's a Node.js Meetup we hold once a month.  I'd love to get

> together and chat.  You can find us athttp://www.meetup.com/DetNode/.

>
> I'm also interested in chatting with anyone else who's looking to stand up
> similar architectures.  Feel free to hit me up on Twitter!
>
> Thanks.
>
>
>
>
>
>
>
>
>
> On Fri, Feb 17, 2012 at 9:58 AM, Sam Ramji <sra...@apigee.com> wrote:
> > I can't wait to hear how this architecture turns out in production.
>
> > I'm seeing a ton of Node.js adoption and it looks like implementations are
> > getting more and more solid.  The JSON-all-the-way-through benefits look
> > really interesting.
>
> > Tom Hughes-Croucher (ex-Yahoo! and Joyent) is doing solid work on this
> > stuff in real-life/production - you can find him at

> >http://jetpacks4dinosaurs.comand @sh1mmer if you need.
>
> > Cheers,
>
> > Sam
>
> > On Fri, Feb 17, 2012 at 4:42 AM, Kevin Swiber <kswi...@gmail.com> wrote:
>
> >> On Thursday, February 16, 2012, Doug Swanson <dswanso...@gmail.com>

[Mark Derricutt]

Also new to the list here, we're using Restlet for all of our REST stuff in Java as it gives a lot more flexibility and control over what JAX-RS offers, altho it's been awhile since I've actually tried JAX-RS.

On the representation side we've been looking to adopting the HAL format for all of our resource representations over straight object serialization, and in my spare time of experimenting I just just released my HalBuilder library for parsing/generating such representations.

http://theoryinpractise.tumblr.com/post/17847472256/halbuilder-1-0-1-released

I'll be making some more posts on the actual API over the next few days - tho basic usage is mentioned on the github page.

[landlessness]

anyone built an API with Play framework? Or have thoughts on it?

It looks pretty compelling.

http://www.playframework.org/

[Tyler Singletary]

We at Klout are building our next-version API (internally, and externally) on Play for Scala (in conjunction with using Swagger). Our developers can speak to it better than I can, but so far it has gone extremely well.

We'll have a blog post about our experience with it coming up in the very near future.

Tyler Singletary

Developer Evangelist

Business Integrations Manager

Klout

ty...@klout.com

@harmophone

@KloutAPI

[Kevin Swiber]

On Thu, Feb 23, 2012 at 1:28 PM, Tyler Singletary <ty...@klout.com> wrote:

We at Klout are building our next-version API (internally, and externally) on Play for Scala (in conjunction with using Swagger). Our developers can speak to it better than I can, but so far it has gone extremely well.

We'll have a blog post about our experience with it coming up in the very near future.

I think Play + Scala looks really compelling.  I'll be on the lookout for that blog post.

This is actually the first I'm hearing of Swagger[1].  Looking at the spec, it seems a little like RPC in REST clothing.  (Not being judgmental here.  Just an observation.  I don't often discriminate against API's.  Everything has its right place, even the platypus. ;) 

I'm curious how this works out for you and what some of the factors were in choosing this design/technology.  Cool stuff.

[1] http://swagger.wordnik.com/spec

[Peter Rexer]

I'm thinking about looking at using Ronin and Gosu to try to do some API work.  Anyone ever touched that?

[Doug Swanson]

Anyone seen an API developed in more of a pure web development
language like coldfusion?

[Kin Lane]

Unfortunately I have.  

A dirty little secret is SAP SAPPHIRE annual event and Google I/O event registration all runs on web services built on ColdFusion, running in the AWS cloud.  

I architected it.  Not entirely proud of it, but It was the platform I was given...and it works.

Kin Lane

API Evangelist

[Luke Stokes]

I used to work at Dave Ramsey's organization and they have a pretty
solid set of services they are building out that run on ColdFusion
using the Mach-ii framework. Doug Smith put together a presentation on
it if you're interested: http://blog.mach-ii.com/building-restful-service-layers-presentation

[Doug Swanson]

> Unfortunately I have.
>
> A dirty little secret is SAP SAPPHIRE annual event and Google I/O event
> registration all runs on web services built on ColdFusion, running in the
> AWS cloud.
>
> I architected it.  Not entirely proud of it, but It was the platform I was
> given...and it works.
>
> Kin Lane
> API Evangelist

I'd be interested in hearing more about this if you'd care to share.

We're a coldfusion shop that's looking at breaking the business logic
out of the cf web applications and building a more flexible RESTful
API layer that could be used from internal AND external apps.

The path of least short-term resistance would be to continue using
coldfusion - we have in-house development and operational experience,
the code porting would be much simpler, etc.

But I'm wondering if using a more general purpose and more widely
supported language like java, while requiring a bit more short-term
overhead, wouldn't be a better choice long-term.

[Kin Lane]

Happy to share.

Feel free to email me directly.

I totally understand the ColdFusion resource issue....I successfully ran the company which was all CF based and got the job done.

Not trying to bash ColdFusion...if it is the resources you have...make the most of it.  

Kin lane

[Daniel Roop]

I would imagine any tool you are using to build web pages is probably more than capable of serving resources...even cf.  Something like fusebox or cfwheels if those are still around have all the constructs you need.  we happen to use apache cxf (Java)  at my office and it gets the job done but it is ahh little too Java-y and not enough web-y for my taste.

The thing to remember is that rest is a description of how the web works and we are applying it to services.  So all the same approaches that work for web pages are probably a good fit for apis. MVC, link helpers, partial templates etc...

[Dan Magnuszewski]

I build my APIs in Perl, with the Catalyst Framework. Works very well and I have the power of CPAN at my disposal. For backends, I've used MySQL for relational data, MongoDB for document based NoSQL, and Neo4j for graph db needs.

http://www.catalystframework.org

http://search.cpan.org/~bobtfish/Catalyst-Action-REST-0.98/lib/Catalyst/Controller/REST.pm

An overview of REST and Catalyst:

http://www.slideshare.net/jshirley/no-rest-for-the-wicked-rest-and-catalyst

-Dan

On Thu, Feb 16, 2012 at 5:47 PM, Doug Swanson <dswan...@gmail.com> wrote:

New to the group and really loving the discussion of ideas.

Hope this isn't "out of bounds" to ask but I'm curious to know more
detail about what specific implementation environments people are
using - language choice etc.

We're looking at building a RESTful API, leaning toward Java (looking
deeper at JAX-RS implementations) and started wondering what we could
learn from what others are up to.

[Zolzaya Erdenebaatar]

I'm building my API in Ruby with Grape. It's works well and powerful.

--

Best wishes,
Zolzaya E. - Developer

"USI" LLC
Building of Enkhuud center, 4th khoroo, 15th khoroolol
Bayanzurkh district, Ulaanbaatar - 51, Mongolia

Mobile: (976) 88001963
Phone: (976) 70151145
Fax: (976) 70141146