views:

638

answers:

2

Hi There,

We are in the process of building a REST compliant API. The backend is implemented in PHP and we want the interface to follow the convention over configuration motto.

Many of the API consumers will be Rails developers, and following a TDD strategy to building out the API, we've considered using ActiveResource to implement a consumer while shaping the API to comply with these standards.

Has this approach fallen out of favor? What other options or conventions might we be able to adhere to so that we can feel comfortable having built a strong API (Like Flickr, Facebook, Twitter, etc.)?

Thanks for any pointers.

Chad

+1  A: 

Using ActiveREsource conventions for mapping HTTP methods and urls to API actions is a good idea, especially if as you say many of your users will use Rails. In addition to that I advise you to read "Your Web Service Might Not Be RESTful If…" as just properly handling GET/POST/PUT/DELETE is not the all that is needed to be really REST. BTW, many of the apis you mentioned are not really REST.

Vitaly Kushner
Thanks Vitaly. Gotcha about the other API's - as per usual the goal is always to model the successful well designed ones!
Chad
+1  A: 

ActiveResource requires the XML to be pretty verbose, and IMO not very well designed (nesting of entities can be a real headache)

If the vast majority of your consumers will be Rails developers then maybe using ActiveResource compliant REST services might be the way to go, but they will look pretty ugly to non-Rails consumers.

If you want any technology to be able to consume it, I would not use ActiveResource, and would create XML (or JSON) that suits the data.

I have built a few systems that communicate using ActiveResource, and more recently I have found it easier to do as I suggest above.

DanSingerman
Thanks Dan... this is good info and pretty close to what we had in mind.
Chad