使用REST API作为网页应用程序的服务器端

Question

We have web applications that we build internally (server side exposes web-services that are called from client side JS). We also required to expose our code functionality in REST API.

I wonder - should I also start to use the REST API also for the web application that I build internally?

Originally, the REST architectural style declares that the REST is stateless ( http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 ). This results in consumers\\clients that keeps the state in the client side. It works well for "rich" clients (mobile applications, etc...) that are built to save the state in their side. But... is it the same for web applications? Is it good to have server side that expose itself in REST API, and the client side calls those REST API directly?

I see some pros, and some cons.

Pros:

• Unified interface - our server side exposes it's API only in one way (REST), for the web application, and for general purposes API
• Easy to expose services that we use internally to be used by external users.

Cons:

• As said above - browsers are not built to save cache in the client side.
• If I have the possibility to use state - why not? It improves performance (less back and forth), and ease on development.
• Once we expose the internal API to customers, it restricts us to be very careful with the changes.

Any hints\\recommendations?

Answer 1

This is an extremely common and powerful architecture, especially when coupled with heavy front-end clients like AngularJS or EmberJS. The state in that case is held on the client, and passed to the server only what's needed to complete whatever interaction (API call) they're making. It's really clean and scalable, in my experience.

A couple things you need to figure out / handle. Login & "session" info. In general, session stuff doesn't get done on a REST service ,so you have to account for that in various ways. Login is generally done by acquiring a token from the server (eg a JavaScript Web Token) and then passing that on further requests. You end up handling expiration on your own.

Answer 2

Using single REST server for all your applications will enable you reuse of the server. Regarding sessions, in Kaltura we use login to return an encrypted string that holds the user id, his session type (admin/user) and the session expiration, once the client received that session string it will use it for any future API call. This architecture enable us to save additional information on that session string without keeping a copy of it on the server.

For more API REST server guidelines, see my blog: http://restafar.com/create-new-rest-server/