Hey guys I need general help with identifying what an intermediate REST layer is called.
I am developing a solution that relies on the user data of a video game company. The company has REST APIs that I can call to gather the data, and I have decided to take the following approach: build a website with React, build an intermediate layer using Spring-boot which will provide APIs for the website and also call the company's APIs to gather the data. Say I want to research best practices for that intermediate layer be it caching for example, I am having trouble narrowing my search down to specifically cater for my architecture.
So what would you call that intermediate solution?
If you think I have design flaws, advice is greatly appreciated.
Since, your application is acting as a think layer of proxy a backend for frontend application architecture (BFF) might fit better.
A BFF is, in simple terms, a layer between the user experience and the resources it calls on. When a mobile user requests data, in a BFF situation, their request is translated through the BFF and into a general layer below it.
Related
Let's suppose I was going to design a platform like Airbnb. They have a website as well as native apps on various mobile platforms.
I've been researching app design, and from what I've gathered, the most effective way to do this is to build an API for the back-end, like a REST API using something like node.js, and SQL or mongoDB. The font-end would then be developed natively on each platform which makes calls to the API endpoints to display and update data. This design sounds like it works great for mobile development, but what would be the best way to construct a website that uses the same API?
There are three approaches I can think of:
Use something completely client-side like AangularJS to create a single-page application front end which ties directly into the REST API back-end. This seems OK, but I don't really like the idea of a single-page application and would prefer a more traditional approach
Create a normal web application (in PHP, python, node.js, etc), but rather than tying the data to a typical back end like mySQL, it would basically act as an interface to the REST API. For example when you visit www.example.com/video/3 the server would then call the corresponding REST endpoint (ie api.example.com/video/3/show) and render the HTML for the user. This seems like kind of a messy approach, especially since most web frameworks are designed to work with a SQL backend.
Tie the web interface in directly in with the REST api. For example, The endpoint example.com/video/3/show can return both html or json depending on the HTTP headers. The advantage is that you can share most of your code, however the code would become more complex and you can't decouple your web interface from the API.
What is the best approach for this situation? Do you choose to completely decouple the web application from the REST API? If so, how do you elegantly interface between the two? Or do you choose to merge the REST API and web interface into one code base?
It's a usually a prefered way but one should have a good command of SPA.
Adds a redundant layer from performance perspective. You will basically make twice more requests all the time.
This might work with super simple UI, when it's just a matter of serializing your REST API result into different formats but I believe you want rich UI and going this way will be a nightmare from both implementation and maintainance perspective.
SUGGESTED SOLUTION:
Extract your core logic. Put it into a separate project/assembly and reuse it both in your REST API and UI. This way you will be able to reuse the business logic which is the same both for UI and REST API and keep the representation stuff separately which is different for UI and REST API.
Hope it helps!
Both the first and the second option seem reasonable to me, in the sense that there are certain advantages in decoupling the backend API from the clients (including your web site). For example, you could have dedicated teams per each project, if there's a bug on the web/api you'd only have to release that project, and not both.
Say you're going public with your API. If you're releasing a version that breaks backwards compatibility, with a decoupled web app you'd be able to detect that earlier (say staging environment, given you're developing both in-house). However, if they were tightly coupled they'd probably work just fine, and you'll find out you've broken the other clients only once you release in production.
I would say the first option is preferable one as a generic approach. SPA first load delay problem can be resolved with server side rendering technique.
For second option you will have to face scalability, cpu performance, user session(not on rest api of course because should be stateless), caching issues both on your rest api services and normal website node instances (maybe caching not in all the cases). In most of the cases this intermediate backend layer is just unnecessary, there is not any technical limitation for doing all the stuff in the recent versions of browsers.
The third option violates the separation of concerns, in your case presentational from data models/bussines logic.
I've been reading around trying to understand what RESTful API is all about. I guess I understood the general outlines and a bit about how it's related to HTTP and all that.
In fact, one of the jobs I recently applied for required a 'must' knowledge of a RESTful API!! The job description was messy anyway and seemed it had been written by an HR person, or somebody who didn't actually have an advanced technical knowledge.
I fail to see how, as a frontend developer / UI/UX designer, I could benefit from the vague RESTful API stuff? What's the connection?! Should really be bothered?
Thanks!
Simple and Precisely NO.
For only a front End Developer; it is not necessary, it is must (or SOAP bases API) for BackEnd Application Developer.
I am Android app Developer, made REST api for my app and my friend is just working on Web Page UI for that APP.!
Ajax calls are little to know for you.!
But one should know little bit about APIs, it never hurts :)
RESTful api, and web services in general, are a way to abstract back ends from front end developpers. It allows front-end developpers to do their interfaces without the need to code any server-side logic.
Web services contain all the business logic. As a front-end developper, you'd need to know how to interact with such services, but the whereabouts of the api call are not required of you to understand.
Finally, it's a way to define clear separation between what the application looks like and what the application does.
REST is a way to think applications. To make short, the client is stateless and you use HTTP methods for what they are designed to in order to interact with your server resources. You also leverage HTTP status codes, media types, content negotiation (Conneg).
If you want to know more about principles of RESTful services and Web API, you could have a look at this link: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Hope it helps you,
Thierry
From client perspective the two main differences between REST and other e.g. SOAP webservices, that you have to use stateless communication (so you won't have a server side session, login, logout, etc...) and you have to use hyperlinks as request templates instead of building request from scratch. Because of these constraints your client breaks much harder by API changes.
I'm looking to create an ecommerce website, however I have two possible ideas for the structure of the application.
The first idea would utilize MVC 4 and have an EntityFramework layer to communicate to and from the database. This is fairly straight forward but I don't like the idea of having ALL of the processing happening on the front end of the website.
My second idea was to have a web service that sits in between the MVC application and EntityFramework. This would be responsible for most of the website processing, and would expose only necessary information to the front end of the website to minimize the amount of processing on the front end of the website.
Would this be a better solution, or is there another solution which would be better?
You should make a difference between logical and physical layering.
To avoid premature optimization, you can have all the logical layers you want inside the web application itself (the traditional presentation / business / data approach or another pattern, for example onion architecture).
Later, if needed, you can always optimize and move parts into their own physical layer, and in that case you would have a web service or web API in between. But it all depends on your requirements (multiple consumers of the services?) and environment. You could just as easy scale the web site itself, for example.
So in your case, think about what added value this additional abstraction would have, and if it's worth the extra complexity.
Running all traffic an EF access through a web service layer internall has the following benefits:
It runs up your budget because you do add a lot of slow processing overead (string parsing) into a high throughput low level interface.
It absolutely makes sure you have a low performance because of the added latency.
It totally makes sure you spend a lot of more working hours to get a solution because you need to implement and test a web servie for any small database access.
THere is no reason to run anything internally through a web service interface. It is architectural cancer - out of control complexity growth. Web services are a user interface layer and a trust boudary and should be the end of an application. If you make a web commerce website (and most likely that is quite trivial and small compared to something like amazon) there is no need to get involved into elements that make things a lot more compelx without any gain.
DEPENDS!
Building an eCommerce web site from scratch I would use a client mvc web site with a responsive pattern in mind, so it will fit to all devices , and use EF WebApi as the data layer to generate XML/JSON.
We Love Play!!
Have used for small projects and pleased with the performance and productivity.
Need few suggestions or comments for the architecture for our new venture which is going to be on play-framework.
Our new venture is to use REST Service stack built in
play-framework(Java) with any front end MV*. Moreover a SOFEA model.
Would like to see how secure we can make our application coz the app has some sensitive data in few endpoints.
Question:
Does the design has any flaws
What is the best way to secure our REST service stack
Is it advisable to decouple my front-end app and back-end services
Which front-end framework is best for this scenario.
Thanks
Kindly suggest appropriate stack site if the question is Non-constructive rather just downvoting ;)
Edit: Anyone care to suggest / anwser? Added bounty.
With any REST-based application, a main security risk is that you have no control over the client. All data and REST requests being sent to the server must be fully checked for authorization. That is: check that the user allowed to view this data and perform the action being requested?
I agree with #johanandren about the first one. It is impossible to say without in depth analysis of the design and the code.
Maybe you should have a look at the Flask framework for REST architectures. It is nice and it has very good add ons for security.
There is also a very good tutorial about it.
I am not sure what you mean by the last question. But if it is about how to return the data. Usually json is a good solution.
Good luck with our play project.
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.