21

The company I work for maintains a successful SaaS product that grew "organically" over the years. We are planning to expand the line with a suite of new products that will share data with the existing product. To support this, we are looking to consolidate business logic into a single place: a web service layer. The WS layer will be used by:

  • The web applications
  • A tool to import data
  • A tool to integrate with other client software (not an API per se)

We also want to create an API that can be used by our customers that are capable of using it to create their own integrations. We are struggling with the following question:

Should the internal API (aka the WS layer) and the external API be one in the same, with security and permission settings to control what can be done by who, or should they be two separate applications where the external API just calls the internal API like any other application? So far in our debate it seems that separating them may be more secure, but will add overhead.

What have others done in a similar situation?

Improve this question
3
  • If you buy a nice framework for SOA, all of this debate is moot. Are you planning on rolling your own SOA framework? Why? If it's a successful product, why not license JCAPS from Oracle? Or WebSphere from IBM? Then the security of the WS layer becomes ubiquitous and transparent.
    – S.Lott
    Feb 24, 2011 at 11:05
  • 1
    @S.Lott It's really not that difficult to write a SOA layer. Neither of those platforms are REST-based; this is 2012 isn't it? Those sound awful 'enterprisey'.
    – Evan Plaice
    Dec 13, 2012 at 4:09
  • Why not to have a service layer on the top of your domain model, then you can use the same services internally with your source code.
    – M.abuelezz
    Oct 2, 2014 at 18:10

5 Answers 5

Reset to default
16

It is always good to eat your own dogfood. One API should also be simpler to maintain than two, even if you factor in some overhead for authentication and authorization.

Improve this answer
1
  • 5
    I like the way you put that. Having two separate layers is ultimately going to mean changing things in two places a lot of times in the future, additional testing, and lots of general insanity trying to figure out why things got out of sync. If I had enough reputation to vote up your answer, I would :)
    – Drew Goodwin
    Feb 24, 2011 at 5:56
7

I've encountered this before (many times) and what I've ended up doing preferring is:

Take the BL out of the website. Make the website a consumer of the API. Treat the website as just some other client of your API. Your API IS the service.

If you find yourself thinking that you need special API methods just for the website, think again! If its good for the goose, it is good for the gander. If you really really really need special functionality for the website I would suggest that what you've really found is a difference in "user profile" and therefore this is a situation where the API should still support the "special" functions, but then you control them via authorisation.

Not convinced?

Take the paradigm a step further ...

The phone app is running on a platform where bytecode is executed, the app lives in the phone and consumes API services via HTTP/JSON

The website is an app running on a platform where HTML+Javascript is the executed, the app lives in a the browser and consumes API services via HTTP/JSON

Same same!

Extend that to tablets, TVs, other phone platforms, plugins, third party apps, mashups, ...

Lots of different user experiences all plugged into a common API.

Your app IS the API. The website is just one client (of many)

Improve this answer
1
  • Comprehending that the API is the entire application layer, and the various versions (OS, browser, tablet, phone) are just clients of the API got me to the A-Ha! moment just now.
    – AJB
    May 19, 2014 at 2:51
6

Although I agree with Aneurysm9 sometimes you do not want to expose all the capabilities of your system. In this case having two API would be preferable... BUT if you do so chose this way... do make sure that all common functionalities share the same API, IE that one be an extended version of the other as opposed to two distinct sets of code.

This way you get to use your own for yourself while having a place for private, sensitive, experimental work to progress while still enabling you to publish and use the new stuff without changing the public API too much.

Improve this answer
2
  • 3
    I think we're in agreement here. Use the security layer to restrict the superset of functionality to internal users. That way, you've got one API but multiple levels of permissions to access the API.
    – Aneurysm9
    Feb 24, 2011 at 14:42
  • I'm thinking about doing this myself and handling it by making my app a user of itself with elevated privileges. Tricky to wrap my brain around. I think I need to apply Hammock Driven Development on this one.
    – AJB
    May 19, 2014 at 2:44
3

Use one API

If you're implementing the service API as a REST layer, just add authentication to the routes that are protected.

You'll probably want to use a development framework that doesn't bake in too much 'magic'. Something where you can define routes directly without a whole lot of reverse engineering.

Think something like Node.js/Express, python/pylons, python/google app engine, etc.

I recently implemented this on Google App Engine for a REST/Datastore API and I don't think it could have been easier. Controllers are implemented as classes and their subsequent HTTP requests (ie GET/POST/PUT/DELETE) are implemented as methods of those classes. I managed to implement basic-auth as a decorator. That made adding an authentication requirement to a request as simple as attaching the @basicAuth decorator.

That way, I could make incoming GET requests public add an auth requirement to POST/PUT/DELETE requests on the same controller for that model.

If you know how to speak in REST, life becomes a lot easier because REST support is already inherently baked into ever webserver (ie HTTP is just a type of REST API). You can even opt for transparent gzip compression if you're sending a lot of data across the wire.

Improve this answer
-1

My first impression is that it should be the same API, and that your security should be on a different layer altogether. Perhaps handled by a web front?

Improve this answer
1
  • 2
    sometimes security concerns will dig much deeper than the mere encryption and signature of transactions. As such it is quite possible that some, or even a lot, of security oriented elements creep up in your main API. This said, I would agree with you in trying to keep it as separate as possible.
    – Newtopian
    Feb 24, 2011 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.