1

I already have experience working with MVC based web apps and started reading recently about REST.

But went into confusion when re-thinking about how existing web app not using any kind of framework/pattern could be refactored to use these two.

So the application (entirely written in PHP) already has a web UI but it's not using any patters like MVC (everything is lying around in many places with no separation of concerns).

I already have an idea of how I can refactor it to follow MVC. (Writing controllers for request from web UI, delegating request to a service layer which interacts with data layer and so on).

What I also want is to enable a REST API for some of the functions.

I think the service and data layer would be used by both of them.

But how should I handle the requests for Web UI and for REST request? Should I use separate controllers - one for web and one for REST?

Also, since REST is stateless, how should I handle state (like session which would be needed for web ui interface)?

Improve this question
6
  • Seems to me like you need two ASP.NET MVC projects; one for the REST interface, and one for the Web UI. But at the end of the day it's just more controller methods. Commented Jul 28, 2016 at 21:18
  • @RobertHarvey apologies that I didn't mention that it's PHP based(edited my question now), but that should not make much difference. Commented Jul 29, 2016 at 7:55
  • 1
    As you probably don't want to change the behaviour of the existing WebUI too much, I would advise to use separate controllers (responding of different URI endpoints) for the WebUI and the REST API. Those controllers would share the service and data layers. Commented Jul 29, 2016 at 10:25
  • 1
    @Abbakkar I think you are confusing terminology some what here. "REST" is the web, HTTP is a REST protocol. REST is an architectural design that the web conforms to, including webpages read by browsers. I think you might be confusing REST with something like a JSON API instead of HTML webpages (understandable, people keep making that mistake). Commented Jul 29, 2016 at 13:33
  • I noticed that you put a bounty on this. What sort of authoritative or credible source did you have in mind? How will the authoritative nature of that source help you write your application? Commented Aug 3, 2016 at 20:06

7 Answers 7

Reset to default
1
+50

Let's assume that if you're talking about a MVC design then you're talking about a server side implementation. The (UI) controller will accept a request, invoke business logic (model), render a view and return it to the client.

Let's assume that if you're talking about a REST version of a website, you are moving to a partially client side implementation. Your client, presumably in the browser, will accept a request, determine which REST interface to call (model), and render a view directly on the client (browser).

There are many client-side frameworks for accomplishing this, AngularJS ReactJS, EmberJS, to name a few JavaScript ones. When you want to update/rework a website in this fashion, then you put your existing business logic into REST endpoints and call them from your new client framework of choice. There will no doubt be detailed suggestions on how to keep client state in the chosen framework.

The challenges you will face will involve breaking down the business logic into responses that can be easily serialized and make sense. For example, where you used to retrieve all the data for all the customers and display either a summary of all customers or detail for a specific customer, now you need two separate REST endpoints, one for a summary of all customers and one for the detail of a specific customer. While such a change is generally an improvement to the system, it doesn't necessarily drive whether or not you want to use a server-side framework or a client-side framework.

Client-side frameworks may have to run on any browser or cell phone that comes to your site, and may not be suited for highly complex websites. Sensitive data exposed to the world by REST endpoints may not be a good idea. On the other hand, client-side frameworks can enable a website to really cool stuff and may improve responsiveness if done well, but the overall effort required when adding client-side code probably equals the square of the product of the complexity of the website and the number different client platforms you must support, so watch out.

Improve this answer
5

First what is a RESTful API

To clear up a few things RESTful APIs (aka a service) are a means to have your applications communicate. You create a service and then many clients that can make request to it.

What is a client? These are many things like the front-end web UI, a reporting engine, the invoicing system, search and so on.

So in your example you would be building a RESTfull API service for the front-end client to make requests to. A RESTful service will send the data back usually as json. The client then process that response processing further and displaying as appropriate.

One thing to note here is yes the service is stateless but the client is not. Your client can have sessions and cookies. It will have to pass that information in the request to the service for processing using the the response to update the state.

So for example a client could make a call to routes like:

/user/create //A POST request with all the information needed to create a user /user/{:id}/profile //A GET request to find get the information needed for a //user profile with whatever the id is.

So a RESTful API is a high level architecture for the applications' communication.

Where is MVC in this?

A step down into an application is where MVC (as well as MVP, MVVM, etc) is used to create separations of concern. These patterns help so you do not get disparate piece and parts all over the place and more logic in your views then html. You would see this implemented within the front-end client because the service does not care about views just the data (view is the V in MVC).

To break down MVC:

(M)odel - is a container more or less to hold the data. It could be a user model or a larger model like profile that has a user, cart, payment, etc. It has a known structure and elements and probably some methods for data manipulations.

(V)iew - is the way to display the information back to the user (browser with HTML). This could be a php page that takes in the above model and parses it to the various section of a page. One thing that is pretty agreed on here is that this should not contain much logic. It is mostly presentation of data that was gathered.

(C)ontroller - orchestrates the application. Based on where a browser request hits it knows where to get the information to fill the model in this case a request to the RESTful service API. That model is then feed into a view and then sent back to the users browser.

Summary

The beauty of creating a RESTful service is that it can be in anything and then the client can be in anything just as long as you can make calls over http/https. The MVC is used in a client that manages how users interact with that API.

Implementations

Now as for an implementation in PHP check out some of the frameworks Laravel, codeignitor, symfony and yii all come to mind (I have used 0%) and see if any fit your needs.

Note your could home grow the service and then pick a framework for any of the clients usually I build my service in PHP or Java (PHP has slimeframework and Java JAX-RS) and then choose whatever hottness I want to use for that day in the client (Angular, React, GO, or more PHP, hopefully not Java).

Improve this answer
1

Where the REST API and the Web UI have the same functionality and the only difference is the format delivered, use the format requested (.json or .xml suffix on the requested path as opposed to .html) to decide which view to use to format the objects produced by the controller action. That's going to work best where the web UI was designed as a RESTful application in the first place. Where there are significant differences in flow and the requests made by the REST API vs. the web UI, it would be better to separate the two within the same web application so they can share common business-logic and data-model elements. The application could have a web and an api namespace for controllers and views, with paths beginning with /web/ or /api/ depending on which namespace's controllers were going to handle that request.

When it comes to session state, even the web UI should endeavor to store as little state in the session as possible with the goal being for all needed state to be stored in the database or other persistence store or as part of the path (eg. pages related to a given user have the user ID in the path). The session normally contains only things like an authentication token (to verify that the user had authenticated correctly) or the username or ID they authenticated as. That could be needed just as much by the REST API if it was designed with an authentication request which checked credentials and set the authentication token just as the web UI login action would have.

Improve this answer
1

I have little experience from which I will try to help you out. Once you port the app to use MVC, then comes your need to apply RESTful way of interaction. RESTful way will mean: 1. there are resources that you are trying to expose, and not services, and clients get access to them with proper URLs. 2. use HTTP verbs Read here: https://www.ibm.com/developerworks/library/ws-restful/

Further, to maintain state in the RESTful mechanism, you have to pass back and forth authentication tokens. For example, you can make the client login before accessing your server. Then, in login response, return some authentication token. And let the client use that in request header for further secure calls, which you can always validate using, for example in Jersey, SecurityContext.

Now, to maintain state, you can make it either client side (cookies, browser localstorage etc), or server side (so you can validate context on every request and decide to renew or end state as per implementation). Because the URLs wont know anything about state, they can just carry the sessiontoken in request headers if you implement so, and the location of the resource client in trying to lookup.

Improve this answer
1

Good that you decided to move to MVC, time proved easy to maintain. My suggestion is to go with a simple framework like codeigniter.

While designing, make sure you move out your entire logic to a services layer, and use controllers just to do the controlling part alone. So your web controller will fetch the data from the request and put it in your entity, which you pass to the service. The service will have business logic, database etc and respond back using entity. Similarly, when you talk about REST API, that too becomes a controller which does take the data from post or get params, places it in entity and passes to the same service which you wrote earlier. Thus you are re-using services.

Coming to session issue, dont save anything in session as much as possible.

If at all you need to use some caching technique available with the framework of your choice or something like memcache, redis etc.

hope this helps.

Improve this answer
0

You're asking questions about a framework in a piecemeal fashion, it may be better to just review a MVC web application framework which provide direction on the topics you're asking about. (REST, Session state, separation of concerns) If you're planning to continue to use PHP then why wouldn't you consider using Ruby On Rails? It's a popular MVC framework which also integrates with RESTful designs. This site, http://guides.rubyonrails.org/getting_started.html, provides a starting point.

Improve this answer
0

Refer this link best-available-php-restful-micro-frameworks and find a framework which suites your need to port your idea/implementation from traditional to MVC based rest supported application. The site has listed the frameworks for php which provides sophisticated features to create service based apps rapidly.

I would suggest to take a look into laravel framework which is a matured and sleek, could help you out to accomplish the requirement. .

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.