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?
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 (e.g. a JavaScript Web Token) and then passing that on further requests. You end up handling expiration on your own.
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/
Related
I am tasked with a web application project involving a lot of dynamic design.
I am going to build a RESTful API with Node.js with token-based authentication, and initially I thought about building another Node.js application for web-based UI, but now that I have a basic design of the API, I was wondering if it is feasible to implement all of the UI logic with JavaScript on the browser?
It would involve a HTML page, which has JavaScript that will GET/POST data from the API, and update the DOM accordingly, furthermore, I would save authentication token in cookie, and the JavaScript in browser would do everything ranging from login to updating/deleting/creating all kinds of data through the RESTful API.
I haven't heard anything quite like this, is there any security concerns? Off the top of my head, the API server would get tremendous amount of requests if attacked.
Regardless of the amount of traffic or code, the security concern is the same.
Is anything sensitive being sent to the browser?
Is any request to the server not being validated?
That's pretty much the extent of the security. Any attacker can craft any bombardment of requests to any API, regardless of how complex the client-side code for the application is.
Assume that client-side code might not execute at all. Assume that you have no control over the client-side code. Assume that every request reaching the API must be validated. Assume that any input coming to the API can't be trusted. Etc.
Basically there are no additional security concerns which wouldn't exist in any of the simplest web applications.
I'm designing an architecture where the web interface is a client (developed using a front-end js framework) and all requests are routed to several webservices.
All communication will happen using standard HTTP responses and JSON entities.
Now I'm facing the authentication mechanism.
My service will, of course, have several users, and I need to restrict access to users' resources.
Users will 1) signin to the web client (/admin) and then 2) the client-side js will perform several AJAX requests on webservices on user behalf.
Should I create a persistent session between the client/server and then pass some reference alongside each request or authenticate each single request using a stateless approach? How could I authenticate the web-client requests for the current user without adding too much overhead or complexity to my system?
I'm looking at passport-local and passport-localapikey but it's not very clear to me if I should authorize my client or the user itself (meaning should I have only one pair of credentials for all users when performing web-service request or one pair per user?)
A simple example (explained I don't need to copy-paste code) would be very appreciated. At this stage I'd prefer the solution introducing less complexity but granting a good security in order to be able to set it up very quickly.
PS. I could also take into account creating a distinct service handling authentication in order to create a common API to be shared between client and server, but that seems a bit over-engineering to me.
Thanks,
If you're already using Express as a framework for Node.js, you can use it's built in session handling. It is capable of using any sort of session store including memory, redis, mongo, etc.
There's a good example here: http://blog.modulus.io/nodejs-and-express-sessions
With very little experience designing mobile or web based systems, I really have no idea idea what sort of methods are generally used for exchanging information from an application on a phone with a web service on a server. In my scenario, the app is on Blackberry 10, and I think the web service will be run on Heroku.
I want to periodically exchange small amount of information between client apps and the server's web service. I have tried searching for how this might be done, but I have had no success in finding anything helpful. Any sort of information on how I can or should do this would be appreciated.
To clarify a little: I am particularly interested in how small amount of data are typically stored for transfer, and then what mechanisms are generally used for actually sending and receiving the information.
Typically, this is handled via HTTP calls through the mobile device's SDK. I have no idea what the objects are on blackberry, but the typical workflow looks like this:
Write a web service that does something (e.g. calculation, retrieve data, store data).
Publish web service to a web server. This web service has a URL. If you are following RESTful approaches to web services, there would be unique URLs for resources available through the web. Each function that the web service performs uses one of the common HTTP verbs, e.g. GET and POST. You use "GET" to retrieve data from the web via the URL. You use "POST" when you also want to send data to the web.
From the client SDK (e.g. iOS, Android, Windows Mobile, Blackberry), build an HTTP request through the standard objects that are components of the SDK. Sometimes there are open-source libraries that provide wrapper classes that make this process easier. This HTTP request should either just use the URL (in the event you want to make a GET request), or you should build the request via the "body" of the request with the data that you want to send to the server, in the event of a POST request.
Both types of requests typically produce a response from the server, which you then handle and parse using objects and events that are typically components of the SDK.
You then do whatever you want with the parsed response in the context of the client.
Although the specifics of the implementation of this pattern can vary, the pattern is pretty consistent across all the major platforms; it's really the only way to do it.
Does web api have more advantage than socket communication when I am writing a software need calling server to function?
If we write a web api,do we can take advantage of http, http server, web app framework to do more thing with less work than doing the same function by socket ?
If my client call my server through internet, Do we have not any reason to not implement it as web api ?
I'd say that 'web API' is-kind-of a 'socket API'. While socket API may be basically anything running over sockets, web API is done using the HTTP protocol. That has a bit of limitation but usually the advantages are more important:
You reuse existing protocols and methods instead of re-inventing your own ones. That makes the work easier for you, and much easier for your users who do not have to implement everything from scratch;
You can use existing tools (and even a regular web browser) to debug your API. Well, with socket API you usually can use telnet but with more complex cases, a web browser or any HTTP querying tool is simpler to use;
You reuse HTTP ports 80 (and/or 443). That usually means it's less likely that any firewall will forbid your users to access the ports used by your service;
And after all, if you choose the right technologies, you can reuse them 'in' or even 'as' web pages. For example, you can use AJAX or similar technologies to catch data from your API in scripts on your web page.
Even better, if you just use XML for the API output, you can basically make it an API and a web page at the same time. You simply add a reference to an XSLT stylesheet to it, and whenever a web browser uses that API, it will use it to transform the raw XML into HTML.
Web services only output XML instead of HTML. The reasons why you should create a web service does not differs from the ones for creating a web site.
A web API can be called remotely.
A web API can be called in an independant manner. That means that you can allow you user (and you) to use an other interface that the one you build for the final customer.
You can program the API the way you want. The only requirment is to produce valid XML. So, yes you can use some framework, you are supposed to use a web server as the ones that output webpages.
If the client call your service throught Internet (SAAS), creating a web service allow you to give a new interface. Web services are required in order to use SOAP and to allow refreshing of webpages and also to give the datas to a heavy client.
I've recently programmed a REST web service API that allows another website to sign-up for my website remotely.
I've programmed all the necessary validation and filtering in to the API.
My question is, should I now ensure that my own registration form uses the web service API when handling user registration?
The form itself already has the very same validation, but it would seem to be that it would be best if there is only one method that is ultimately responsible for validation/filtering.
That solution doesn't seem to be the best, either, though because I am now making a REST client to touch my own web services API from the exact same website.
The last solution that comes to mind is to put the validation on my user model, and throw an exception up the web services API when validation is triggered. Are there any downsides to this solution?
One of the major benefits of REST is to define a interface that a remote client can access easily with the minimum amount of coupling between client and server. This is very useful when you do not control the client. This allows you to evolve your server interface without breaking existing clients.
The REST interface should really just be a thin layer over your validation and registration logic. In theory it should be easy for you to re-use that logic in your own website without going through the REST api.
Your website is not on a remote machine and you have control over both the client and server portion so you are not gaining anything by going through the REST interface.