Deciding to use REST based on scale

[Mohan Radhakrishnan]

Hi,

        We have a mobile backend system and a portal to manage devices using an admin. portal. I have read about many other REST principles but I want to know how one decides to use REST based on the scale of the number of resources. So we may have thousands of devices which are in various states. We query and update those states. So here the scale depends on the number of resources that we fetch and manage. This system now uses a REST API but a traditional user session based login mechanism.

I have these questions.

1. What are the benefits of using REST when the number of resources is big ?

2. How does a session based login mechanism in a REST application affect its principles ? It appears that if we use a session for expiring a login in a REST application it doesn't directly affect anything. Should I follow a purist approach here and use a token ?

Thanks,

Mohan

[Chris Mullins]

My opinion, after building APIs at scale, is that to REST or Not To REST is orthogonal to scale. I would choose whatever protocol my customers wanted, and whatever would remove the most friction with respect to development and adoption. 

REST solutions can scale to Amazon / Microsoft / Google scales with well known techniques. The same applies to RPC over HTTP, or even SOAP over HTTP. Leveraging web technologies for scale (load balances, SSL termination, shared SSL state, cloud hosting, etc) along with well established best practices such as avoiding affinity, idempotent APIs, and intelligent API design are all far more important things to consider than a REST or Not REST approach. 

In general, the idea of a session is problematic if it means you're creating affinity to a particular web server. If you're avoiding affinity and instead using cookies / tokens / backed shared state then you're probably fine. 

Don't re-invent auth, as you're guaranteed to get it wrong. Just use OAuth2 and be done. That will give you a well established tooling and implementatin chain, and future proof your design to a large degree. 

With regards to scale, "Thousands of devices which are in various states" isn't scale in the modern sense. One server, and one database, can probably handle that load with no trouble if you're just doing basic CRUD operations. 

Cheers,

Chris

[mca]

If you are *serious* about making sure your application architecture matches your problem domain and delivers all the properties (scalability, reliability, adpatability, etc.) that you require, I think you should read Chapters 2[1] an 4[2] of Fielding's dissertation and SKIP CHAPTER FIVE.

Chap 2 lays out the process of selecting desired PROPERTIES of your system.

Chap 4 acknowledges the REQUIREMENTS of a sytem

Chap 5 is just one example of how to apply CONSTRAINTS to induce the PROPERTIES while honoring the REQUIREMENTS.

Ch05 (REST) just an example, not an end goal.

As Chris pointed out, you can achieve your goals in many ways. some take more hardware, some take more software, some rely on async, some require all comms be synchronous, etc. these are all just technical details you have to work through in order to get the system you really need.

My advice to any of our customers setting out on a new project is :

- identify your desired PROPERTIES

- list your REQUIRMENTS

- select your CONSTRAINTS in order to induce the PROPERTIES w/o running counter to your REQUIREMENTS.

do that and you'll "win" every time.

Cheers

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm

[2] https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Mohan Radhakrishnan]

I mentioned scale from the perspective of API design. The number of resources to be operated on by making REST calls. Not scalability or load or any other technical implementation.  

The session is based on cookies. 

Are there any pointers related to API design based on the number of resources ? 

Thanks,

Mohan

[Jørn Wildt]

I can't help wondering about what issues you are concerned about? From an API perspective you can have *trillions* of resources as simply as http://myapi.com/items/{id} where {id} is an identifier in the range of 0 through some *really* big number.

> How does a session based login mechanism in a REST application affect its principles ? It appears that if we use a session for expiring a login in a REST application it doesn't directly affect anything. Should I follow a purist approach here and use a token ?

How do you distinguish between "session" and "token" ... often a token is used to reference a server side session. So, again, what are your concerns here?

/Jørn

--