views:

195

answers:

4

I'm starting to build a site that as most do, displays data in various ways from a database. I'm building a public REST API as part of this project, and will be designing this in parallel with the main site, as I believe that it's an integral feature.

Should the site itself use the public API when retrieving data, or should it use a different method?

It seems silly to duplicate code in this way, but I'm not sure if there will be a speed issue.

+7  A: 

If I were you, I'd have your application hit the database directly so you don't have the additional overheard of going through the public web services.

Then have your application and the public web services use the same database code so you're not duplicating it.

sectrean
+3  A: 

I would reuse the existing RESTful API unless I witnessed a significant performance issue.

  • There's no point to violating DRY unless your solving a proven problem.
  • Dogfooding the RESTful API will improve it
  • This design will make it easy to embed different views of the same data on different pages
Hank Gay
I couldn't agree more. Using our API also allows us to scale well. Because we don't have to scale different areas and keep access methods in mind.
Till
+2  A: 

No need to go via a web service to grab data when you have access to the DAOs directly.

However I would implement a middle layer so that your webservice view and website view can directly call the same methods in the middle layer to grab data, rather than reimplementing each other's logic - the views only have to validate input and present the output.

JeeBee
+2  A: 

As usual, it depends on what you're doing. Without knowing any real details I would say there are a few advantages to using a different layer from within your web application.

Efficiency
This benefit is probably negligible, but maybe your site is going to get enough hits for the benefits here to be noticeable.

Hidden Features
You probably won't want to expose every feature or every little detail through the web services that your site will consume, so you'll have to create an 'internal' only 'business layer' anyways, so instead of splitting that part up between the public services and internal, you can make it cleaner by doing an entire internal layer separately.

Updating
You can change the way your internal business layer works if you want to change the way your site works (for scalability, maintainability, etc...) without affecting the public API that people are using.

Ease of Use
Just guessing here, but you can probably make your internal business layer easier to consume than the web service.

Obviously there is the disadvantage of some duplicate code, but I think it's a small price to pay in this situation.

Max Schmeling