When designing an API that will be used by both web and mobile clients, do you design a separate API for each, use the same API for both, or use a hybrid approach?

Same for each

I see some good answers here, although I could do a consolidation and give some additional points here. First of all, what I believe is that in most situations, a single API should do the trick. Solutions that even scale up to a "big-data" level or at enterprise level are smart enough to have APIs that return data specific to the requirements of the device (as the question mentioned, the mobile device might not need as much data as other devices). Secondly, at times, when you're building the API, you should make it scalable in terms of number and type of requests (the return fields required), but shouldn't focus too much on making it too smart, giving client application developers the flexibility to decide on the data to be fetched and other parameters gives them the chance to be more creative, although also gives them unnecessary power to make the client slow (your call!). I'll answer the rest of the questions mentioned in the question details: Architecture / Technologies : The fundamental architecture trending these days is a REST based architecture, strictly following GET / PUT / POST / DELETE, studying twitter / quora / aws architecture is a good start towards knowing the current architectures being employed. Most of these architectures are not technology dependent unless you need an IO-Loop / stateless servers (Tornado with Python is a good example to study, Ngnix is also a good example - used quite a lot). Technical Issues : Separating out the real-time section is a bigger challenge than the device dependency, as I mentioned before, the device dependency should be handled by the client and not the API. By real time section, I refer to the notification engine, the chat system, their device support is more important and might require additional API / client level coding. Most of the times, this section is usually kept separate from the entire API as it requires a higher degree of scaling and requests. Fundamental difference in mobile & web APIs : As the other answers have mentioned, creating an entirely new code-base or maybe partially, comes with the maintenance and synchronization costs. In any case, it is assumed that when exposing device specific data, we are replicating most of the client server tasks (for browser based systems) and client tasks (for desktop or native mobile applications). In that case, we need to take care of the markup support, the memory capacity of the devices, screen resolution, the data that can be with-held (classifying basic and advanced information that needs to be sent in one request) etc. APIs from scratch : Most of the systems usually learn and fine-tune from their own mistakes, although, it is advisable to keep any section of your user interface (including the template rendering engine) on a client server rather than integrating it as a part of your native API (for regular browsers as a basic functionality). It pays off later to keep things modular. Most companies deprecate and introduce a better API and calls and updates it's consumers on the same. Fine tuning for mobile : In an ideal scenario, one usually fine tunes the real-time API, the video and audio delivery channels (depending on what all is support on a device to device basis) - this is also a browser to browser dependency, screen resolution fixes (using a grid based system such as bootstrap css). Twitter's real time delivery architecture http://www.slideshare.net/raffikrikorian/qcon-nyc-2012-twitters-real-time-architecture is a good read on the technologies / architecture employed in creating a single infrastructure for device-independent request handling. Hope this helps.

If your API is RESTful, and you've carefully designed the resourced exposed by the API to be 'atomic' in function, there's no reason a single API can not be used by web, mobile, and even purely logical "action nodes" located on the Internet as functional agents. The only information transferred through the API should be functional data, and not ever markup for display on some device. Just like web programming's separation of presentation from function, a web API exposes only operations upon data, returning the results of the requested operations, and never any information describing how that information is rendered to the user. I like to think that my API client is not a human at all, but some logical agent who works directly with the data, never needing any presentation layer at all.

We've chosen to use a single API for all clients as it makes it much easier to maintain. This should then apply going forwards, not just for web and mobile clients but for TVs and other platforms too. We use partial selection for retrieving only the data needed which is ideal for mobile. So for example, you can add the following attribute to the resource URL:  users?fields=name,email,address The API will then only return the data requested.  If specific fields have not been requested, it'll return everything.

For our current platform I decided to go with a single API only approach. The API is the core of everything. It is accessed from mobile, from the website, the admin interface, from our backend queues, and from external API users. Key aspect of this is understanding identity and versioning. This is the sixth or seventh public facing API that I designed and the first one that is actually RESTful enough and well designed enough to support this approach. Some key benefits: The system is much easier to scale Development costs are down (after an initial spike) API is always current Documentation is good for both internal and external (we use http://apiary.io). The system is very easy to extend, with zero downtime. Development of individual parts is completely decoupled, except for API calls. This is a huge benefit, especially when you add business processes or other clients later. Downsides: You lose some velocity during the first couple of weeks of development You have to have an API strategy You have to be familiar with oauth2, scopes and all the associated nastiness. Our technology stack is entirely node.js based, which makes it significantly easier to implement an API only approach. Still keep in mind that this is nothing for beginners.

API philosophy is that of the One Ring of Sauron: One API to rule them all [clients], One API to serve them, One API to bring them all [developers] and with the UX bind them. An API should serve the purpose of reusing your backend without having to do any rework with each new client.

If you are going to separate the APIs you are missing the points. The only separation of APIs you need to consider is: External API - this APIs are developed for interaction between businesses ( Facebook API, SoundCloud API etc. ) Internal API - this APIs are developed for your application no matter what is the client ( web, mobile, tv, watch etc. ) I wrote one article about API and it is really getting started article: http://fenix.agency/blog/api-getting-started/  I am not focused on API from developer perspective only, it is about business and benefits doing the API approach.APIs should be data - centric solutions ( object related ) where you are giving data to client so it can be manipulated. Some actions maybe will require custom logic ( like interaction with payment gateway  and just sending OK / NOT OK response to client.)1.  The general architecture / technologies: Loopback Framework ( NodeJS framework for building API ) Swagger 2.0 ( API specification which can help you to build interactive console on top of .json file, great tool ) Laravel ( Dingo API package ) 2. Technical issues: ACL ( Access Control List, it is different than in other approaches, my recommendation is White Label Method ) Shifting Mindset, when you are doing API you are responsible to receive request, see if you can serve some response and that is it, logic, iteration are done on client side, queries are going over URL ) Hope that will help a bit.

Let us now talk about API authentication. When a user comes in from Web, we typically tend to use server Sessions to authenticate the user. This is done by passing cookies back and forth between the HTTP request and response. So a typical approach taken is to first check Session variables for the User and if the user is authenticated. Now if the same API is used for Mobile, then we force the mobile users to create a session on the server first before being able to call the APIs. That means the mobile HTTP api will have use the same mechanism (cookies) to call the server like a web browser does. To avoid forcing Mobile users to first do web style authentication, build a dual authentication mechanism on your APIs. If the Session variable has a user, then the call is authenticated. Instead if the API has a Basic Auth in its Header then again assume the call is authenticated. But from here on if you heavily use Session variables inside you API code for it to work properly, then you are going to be in a dilemma. So put enough thought into the authentication aspect of APIs if you are starting fresh. If you wrote the web server first and are now thinking about using it for mobile end points then you might have to muck around with the APIs to allow mobile traffic or incorporate some bad architectural practices to get Mobile working.