I've seen many examples of what is called Spring REST which basically all are simply Spring MVC. Granted that using JAXB, and JAXON you can provide XML, and JSON responses, but there is more to REST than just providing text response.
One major issue is that non of these examples mention anything about session; a REST application is supposed to be session-less, but Spring MVC is certainly session-full.
So, does Spring MVC somehow disables session, or are we supposed to disable session when we use Spring MVC to implement REST?
If we are supposed to disable session; then how is it that done?
Spring MVC does not enable sessions until you use them;
I fully agree that the so-called "rest support" in Spring should have been called "pretty urls and Jackson integration", but nowadays it has little market-appeal (even though pretty URLs and JSON are the only thing people associate with REST; that and mapping CRUD to http verbs).
REST is an architectural choice that has nothing to do with sessions (nor pretty urls, nor json). Since it is more of a religion than an actual technique, nobody will translate it for you to a fixed set of practices. You could have sessions modeled as resources that get created when user logs in and that disappear after some time. And so on.
Related
I am using an PHP MVC framework (Yii, but my question could apply to most MVC frameworks) to create a project that should include a web application (website) and RESTful web service. I am facing an early design decision on how to logically separate the application and service logic. Here are some true facts:
The web app and web service will share a lot of functionality and only differ in rendered format (View vs JSON)...
...But, the web app and web service will have some unique features (ie, there will be things that the web app does that the service does not, and vice-versa)
Here are my desires:
I would like to share the common functionality's implementation as much as possible
I do not want the Controller to become unwieldy as a result of combining web service/web application logic
I have a a slight distaste for creating separate web service and web app controllers, especially when they overlap in Actions (other than the rendered format)
I do not want to have the web site consume the web service unless it is really a necessary design decision; I will lose out on a lot of built-in features that use database interfaces and/or have to create classes that conform to available IDataSource and other such interfaces by hooking it up to the web service; also there could be a slight performance decline.
I have thought about it a bit and come up with some solutions below. Please let me know which of these you think would meet my wants or let me know if my wants are not reasonable/counter-productive.
Implement completely separate controllers for WebApp and WebService (modularize the two so that they share no code)
Implement separate controllers for WebApp and WebService, but create methods that do the heavy lifting and call those methods to share implementation - for example, if I wanted to do a item/findBySomeCrazyCriteria I would route to the appropriate controller depending on the URL, but each controller would reference some FindItemsBySomeCrazyCriteriaFunction() defined elsewhere.
Make the web app consume the web service (which would require me to expand the planned functionality of the service)
Implement one controller for both WebApp and WebService, which extends from a BaseController that includes generic hooks for REST type stuff in terms of $this->getModel()` and use overrides where necessary
Anything else
Although my question is related to Yii, I feel like this must have come up in the past for many developers. I would like to know what you did/what you recommend to move forward. I am concerned that if I choose the wrong approach I will "break MVC" or somehow regret it later.
Note: you should not worry about "breaking the MVC". Since you have chosen to use Yii, that part has already happened.
The root of the problem lays in the fact that your controllers do a lot of stuff (and thus, violating SRP). What you call "controllers' actually contain also the application logic (that should be part of model layer) and UI logic (that normally would be part of view instances).
What you should have there is a single application, with one model layer and two presentations (what you refer to as "web application" and "web service"). The controllers should be a slight a possible.
You should move the application logic to the service layer through which then the presentation layer would interact with model. You would end up with a lot lighter controller. Then you could be able to provide a separate set of controllers/view for each of the presentations that your project needs with no or minor code duplication.
I would recommend against writing multiple controllers. It is a much better option to keep your domain logic in the models, rather than controllers. Your controllers should only act as the gateway to the logic and serve them in whatever form the client requests eg. as a JSON encoded response or through a view. It would be best if you just keep the task of identifying the client requirements and after obtaining the results from the model translating the response in an appropriate form.
This flow can be streamlined with suitable helpers and a well implemented routing sub-system so that detection of client requirements becomes effortless.
eg. /user/subscriptions.html will fetch an html page where as /user/subscriptions.json will fetch a JSON response.
I'm currently developing a web application, that relies heavily on mobile and desktop clients consulting the web server for information. This can be accomplished nicely making a RESTful API available to handle this. So my idea is to have an application acting as the "platform" which handles all the real business logic and database information behind the curtains.
My plan is to make the platform using symfony2 and OAuth 2.0 authentication mechanisms, combined with RESTful web services.
Now my real dilema comes on the website component. Ideally I would like to think of the website as yet another client that asks this REST platform for information, and completely separate it from the platform itself.
To make it a little bit more clear, let's say we are making a blog with this architecture, so one would have a "platform/backend" that provides a rest service to list articles, for example: /articles/5. This on the backend, and with symfony2/doctrine means that the app has an Article model class, and these can be requested from the DB. A simple controller queries for the Article number 5 and returns all the information in JSON format.
Now the website on this example, could just do the easy thing and also have an Article entity and just query the database directly, but I think it would be cleaner if it could just talk to the platform through it's REST api and use that information as a "backend" for the entities.
So the real question would be, is there anyway to support this kind of design using symfony2? Have entities rely on a REST api for CRUD operations? Or I'm just better off making the platform/website a single thing and share a "CoreBundle" with all the generic entities?
There is nothing in Symfony that prevents you from doing you want.
On the client side you could use Backbone.js or Spine.js.
Have a look at FosRestBundle, it makes your life much easier to create api:
https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/doc/index.md
I have a fairly conventional Grails application. It's monolithic; although it's somewhat split into plugins along functionality lines, it is built into a single war for deployment. Due to company architectural constraints, I need to consider isolating the app's persistence into a web service (or series of web services). What's the best approach to dividing a Grails application into a persistence service and a presentation application?
Put your domain classes in a Grails plugin, and have two distinct Grails applications, one for your web front-end and one for your web service. Both access the database directly, but code for persistence is not duplicated.
Here is a blog post that have some more details on how to realize that.
I don't have an out-of-the-box solution for your problem, and I don't believe there is one. I'll just explain the solution I use and what I would consider in your case.
In my organisation, our approach is to separate our applications in a Grails back-end and a front-end in Flex. The reason is that we have many ready-to-use Flex components that would take too much time to re-implement using pure web technologies, but here's not my point.
Creating a REST back-end in Grails is quick, as views are scaffolded when appropriate, controllers are straightforward, and input validation is greatly simplified by Domain constraints.
The drawback of this split is that definition of domain objects have to be duplicated in the front-end. You might includes objects validation in the front-end or not, but if you omit them, it will have an influence on UI responsiveness (requests to the REST back-end in AJAX calls for real-time validation to get the errors). At the end, our application is quite cumbersome because modifying objects in the back-end implies modification in the front-end. Furthermore, we do validation in both the front-end AND the back-end, and this code is not shared, so it must stay in phase and maintained at two places.
Our applications are split in a way that's similar to two completely distinct Grails applications that would share no code. A solution that would work in your case but is not what you are looking for, for sure.
In your case, I see two viable solutions for the web front-end:
use the Groovy REST client library to fetch and send back your domain objects directly from your controller. If needed, pack them in command objects that reflect your domain objects, so that you can share validation code with the back-end.
create some kind of REST GORM that replaces Hibernate with queries to your REST web service. You could look at the GORM for Mongo Plugin as an example of how to create such a GORM replacement.
I like the last idea, it would be a useful public plug-in. It doesn't exist yet, unfortunetly.
I'm looking for an alternative to the awesome .NET (WCF) REST capabilities.
Why?
I have deep interest in open source technology, but when it comes to webservices I do not have any experience except with .NET webservices.
Besides, I'm currently using a lot of Java and Python, and I am moving away from the Microsoft technology stack.
Please suggest alternatives in any programming language, but explain why it's good or better for some reasons. (this reason may be be tightly related with the choice of language)
What do I want to know?
Ease of use
Installation
Configuration
Generation capabilities
IDE integration
Deployment
Learning curve
Pros and cons
etc.
Spring 3.0 REST:
Spring uses annotation based controllers, which can be used to bind a url to a method in the controller. Annotations are used to differentiate between GET methods and POST methods.
#RequestMapping(value="/hotels/{hotel}/bookings/{booking}",
method=RequestMethod.GET)
public String getBooking(#PathVariable("hotel") long hotelId,
#PathVariable("booking") long bookingId, Model model) {
Hotel hotel = hotelService.getHotel(hotelId);
Booking booking = hotel.getBooking(bookingId);
model.addAttribute("booking", booking);
return "booking";
}
Under the hood, the variable "hotel" in the URI string is converted to a long in the parameter list, as is booking. Spring REST can also marshal JSON objects into custom classes using this same technique. Note that this method is annotated as RequestMethod.GET, which means it's invoked for GET requests but not POST requests.
Spring 3.0 REST makes it easier to create RESTful Web services by eliminating the need to reinvent the wheel or marshal/unmarshal JSON text by hand from/to Java objects.
There is a demo here on the SpringSource Blog titled REST In Spring MVC. The learning curve is low, but getting the demo to work may take some time thanks to dependencies. Once you get setup and have a working demo, the hardest part should be over.
For IDE integration, check out Spring Roo. I've not used it, but I've heard it has some features that integrate with Eclipse IDE to make your life easier.
Restlets:
Restlets were designed solely for REST. As a result, the overhead is a lot lower than Spring 3.0. Restlets are better suited for cases where you don't have a GUI, and where you aren't concerned with MVC. Restlets can easily serve as both a server and a client. It also has an embedded server you can run, which eliminates the need for a container like Jetty or Tomcat.
I've had very little exposure to Python, but from what I've seen of Google App Engine's implementation of the webApp framework, the Router concept feels very similar. Those with a Python background may find the learning curve to be a lot lower:
#Override
public Restlet createInboundRoot() {
Router router = new Router(getContext());
getConnectorService().getClientProtocols().add(Protocol.FILE);
// Serve the files generated by the GWT compilation step.
Directory dir = new Directory(getContext(), LocalReference.createFileReference(new File("war/")));
router.attachDefault(dir);
router.attach("/contacts/123", ContactServerResource.class);
return router;
}
It uses GWT on the client-side; I prefer to take that part out as it reminds me too much of Java Swing. While some people may find that advantageous, my personal preference is to stick with the technologies that feel more like the Web.
Below is a simple example of a REST server using the standalone mode. The server runs on port 8182, and it listens for GET requests. It has a similar annotation-based model as the Spring REST framework, which also helps split up the different HTTP methods and point them at different methods in your classes. This is a very basic "Hello World" REST example:
public class FirstServerResource extends ServerResource {
public static void main(String[] args) throws Exception {
// Create the HTTP server and listen on port 8182
new Server(Protocol.HTTP, 8182, FirstServerResource.class).start();
}
#Get
public String toString() {
return "hello, world";
}
}
Check out the Restlet Web Site for more information and examples of the Restlets framework. Restlets has a slightly less learning curve than Spring because it's targeted to REST; as a result, it doesn't contain all of the extra functionality included with Spring that can sometimes make finding an answer to a problem difficult. Restlets are definitely the way to go if you're looking for something lightweight.
Both of these two frameworks will run in Tomcat, Jetty, as well as on Google App Engine.
If you are using Java and you are familiar with Spring, then you should certainly take a look at Spring MVC 3.x. This version moves away from the ugly XML configuration, and its syntax is very similar to JAX-RS's specs. That said, if you know Spring, then learning Spring MVC 3.0 is going to be minimal. However, if you are having trouble understanding with IoC pattern and what not, then it is going to be a long painful experience. :)
Keep in mind, Spring MVC 3.x is not pure REST, and it will never be in the future at all, based on the Spring MVC developers. Their take was there are already so many good REST implementations and there's no point of making Spring MVC 3.x totally RESTful.
Another option I will certainly recommend to you is Jersey. Jersey is pure REST, in another word, it is an implementation of JAX-RS. Jersey took me 30 minutes to learn. In my opinion, the annotations are so much more powerful and richer than Spring MVC 3.x. The annotations from Spring MVC 3.x seem pretty vanilla to me. Jersey will automatically generate the WADL for you, although it is pretty basic... but having one is better than not having one. You can certainly customize your WADL if you want. (By the way, WADL is REST's version of WSDL, if you don't know what that means). Jersey basically detects your package containing all the Resource classes and generates the WADL based on the configurations you have, pretty neat stuff. The last thing I want to point out is Jersey has a great test framework for you to easily test your Restful web service. In another word, their test framework allows your unit test to easily fire up Grizzly or in-memory server to test your web service. It is certainly one of the best I have ever use thus far. Here's a very easy tutorial for you get your feet wet: http://www.vogella.de/articles/REST/article.html . It is really THAT easy. :)
FYI, I have used both Spring MVC 3.x and Jersey.
ServiceStack is one of the more recent developments. I haven't done much with it yet, but it seems pretty sweet so far.
Ruby and Rails (Ruby on Rails) have great support for RESTful service. In fact Rails supports and encourages design and develop in RESTful manner.
Thanks to ruby's strong DSL feature, writing REST service is very straightforward and easy. Since you have python experience, learning ruby might be easy.
Refer to this guide to have an impression how rest urls (called routes in rails) are defined.
Other Ruby web frameworks such as Sinatra also do a good job on this.
BTW, the best things is that both ruby and rails are open source, and the ruby community is awesome and very active.
There's RESTSharp as a REST/HTTP client (open-source project) and OpenRasta
I welcome you to check out servicestack.net it is designed for simplicity and speed and introduces very low artificial concepts where it is able to maintain a very DRY and succinct API and automatically works out of the box without any configuration or code-gen.
It encourages best practices as it is modelled around Martin Fowlers Gateway and DTO pattern for developing remote services.
The equivalent code for the Spring.NET example above would be
Configuration (in AppHost)
Routes.Add<Booking>("/hotels/{HotelId}/bookings/{BookingId}");
C# Code
public class BookingService : RestServiceBase<Booking>
{
public IHotelService hotelService { get; set; } //auto-injected by IOC
public object OnGet(Booking request)
{
var hotel = hotelService.GetHotel(request.HotelId);
var booking = hotel.GetBooking(request.BookingId);
return booking;
}
}
A similar example to the booking service can be seen by the live Northwind Web Services demo.
That's all the configuration and code (exc DTO) you need to write for that service and it is automatically available via JSON, XML, JSV, CSV, SOAP 1.1/1.2 and HTML endpoints and formats automatically without any extra configuration required.
Checkout the Hello World example for more info on all the endpoints and formats provided as well as the auto generated /metadata and documentation pages.
There is an open source framework entirely developed for RESTful web services which is called Recess
It's not very old, but got good attention from the industry. Alcatel-Lucene already arranged a competition on TopCoder for developing some of their services using this framework.
Check out details at Recess web site
I am a noob to web services world. I need to develop a login validator module and expose it as a service. I want it to be service independent, i.e I should have the option of exposing it as a SOAP service or REST service in the future.
What pattern should I follow ? Sorry if I am unclear in my requirements, I can clarify as per need.
Thanks !!
Edit : I am using Eclipse as an IDE and Jersey libraries. I am not into any framework, simply using the MVC pattern. I find a lot of difference between SOAP ann REST methods, so I want my methods to be implementation independent - i.e I should be easily able to use my method through a SOAP or REST service call as per need. What should I do for maximum flexibility ?
Picking a good MVC framework and understanding how to use it properly can help ensure that your feature is "service independent". Most of the documentation I've read for good frameworks suggest that you keep your business logic separate from your controller.
If you read the documentation for the tools that you use, and ensure that there is a layer between your business logic and your controllers, then that will make the job of switching from SOAP to REST or some other protocol much, much easier.
Since you mentioned you're using Eclipse in your comment below, I'm assuming you are using or are willing to use Java:
Restlets
http://www.restlet.org/
Spring 3.0 REST
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
Develop your service as a POJO. Make sure to respect staless pattern.
Create an EndPoint class for each publication type you require (Soap, Rest, EJB, JMS, what ever)
Use appropriate standard to expose your EndPoint. For Soap and Rest the JAX-WS api and implementations can do it for you using java annotations on your EndPoint.
That's it !