I have done the backend part of a project in java (Maven) and use a Restful design.
The structur in java/(Maven) is:
1) domainlayer
2) datalayer
3) webservicelayer(client)
And the frontend part will be done in groovy/grails.
The only parts I'm doing to write in grails are: controllers and views.
The structur is:
1)Controllers
2) views
My question is how we can link them two parts together. Since Restful part is written in Maven and creates a war file.
How can I get frontend connected to the backend?
One of the really great features of grails is the GORM, so I'm not sure why you'd want to skip that part. Typically you'd only use a controller if you needed to get some data from a backend and then forward to a view. In your case you've already written the backend, so you could actually just do ajax pages that call the REST interface, and that might be all you need. If that's the case you hardly need grails; you can just put the static pages under your project's src/main/webapp folder and you're done. On the other hand, if you want to use grails for the GSP pages, you can make the controllers be do-nothing (so it's just specifying routes really) and have the view be GSP pages that make ajax calls. If you're going to do this be sure to check out jquery since it has really nice ajax support.
REST is talking HTTP so your Grails application will be the client of that. Although, it is a bit wasteful to have Grails in the middle, you can probably design your front-end in JS and do it all in the browser bypassing Grails all-together.
If you are bent on going the Grails way, you will need an HTTP Client (commons HTTP client is a pretty good one) and then on the receiving end you will be able to parse responses, this is where Grails will actually be useful. grails.converters has a nice method for you
JSON.parse(responseText)
It is entirely possible there is a better way of either parsing or doing client HTTP. For example, grails' functional-test plugin wraps HTTP library so you have a bit of a groovy feel for that communication. You might want to look at how it is done there. Not sure if anything better can be done with regards to JSON parsing.
HTH,
Alex.
Related
We are using both Angular and Rails applications at our company. Is there a way to mock a web page to test the UI? Essentially I want to jump midway into an application, so I don't have to take time logging in, creating our object, tweaking the object, then finally getting to what I can test.
I was looking at something like MSL, but am unsure if it's really what I need.
Turns out MSL is what I wanted. My application depends on other applications for communication. In order to isolate my isolation, I can use MSL to mock the responses from and the requests to my dependent applications fairly easily. In my configuration I switch my external dependency to localhost:8001 (or whatever port msl is running on).
Edit
I rewrote MSL, specifically for my purposes and made it a little easier. The server is a node program, and the client is only in ruby as of now.
mobe-server
mobe-client
I am developing a single page app running in desktop browser, tablet browser and maybe phone browser. I am return only JSON from my backend wether it is ASP.NET MVC or Web API.
When I think of Web API or read about it I always hear the words REST/RESTfull. Independently from what REST is I like some features about Web API which I have not in MVC (by default but maybe it can be implemented somehow but I dont want that extra effort...)
Return HttpStatus codes like 200 for GET or 201 when the Ressource is created. My single page app knows and reacts on this codes.
Return DTOs directly in the controller and c# classes are automatically serialized to json. With MVC this is not a one-liner. Not dealing with ActionResults.
Web API is very much designed about 'cool' urls/routing I will also have deep/complex routing on my client.
My Web API endpoints are just 'ajax callbacks' I do not need REST things like include a self.link in every retrieved ressource etc...
Of course I do not create/modify ressources on a Get request. But I already have been used to this style when I was doing MVC. So I like and will do many REST styles but not because of REST itself rather its common practice.
Should I really design great restfull API`s to use the Web API ? I do not know what is Microsofts recommendation about the Web API or wether they have really a guideline about it...
In my experience Web API has often been a great help, and rarely a hindrance. If you do it "their way," it saves you a lot of ugly work around serialization/routing/binding. If you don't want to do it "their way," you don't have to. You can extend the routing engine. You can implement your own serialization. You can return raw JSON where you see fit. Nothing in Web API forces you to follow the REST concept to a T (trust me I have seen this in action). I haven't heard this complaint before from anyone who has used it - I would suggest you give it a try and see just how far off it really is.
REST is not at all required to use Web API. In fact, it is quite easy to turn on and use session management as well.
In fact, while RESTful approaches have some real advantages, I wouldn't recommend going 100% RESTful. It is simply not possible to make them fully secure without using a third-party authentication provider. We built a fully RESTful prototype and explored many different mechanisms to secure the site. In the end, though, every one had one vulnerability or another (it helps to have a CISSP on staff). So I talked to one of the top security experts at Norton and he agreed that, yes, there is always a way to exploit a fully RESTful, standalone app. Symantec is apparently building a "wrapper" technology that gets around this but it was easier to either go with a third-party authentication provider or just go back to MS-based security using session cookies.
I want to build a Rails application that expose a RESTful web service used by a mobile application. I wanna create something maintainable and scalable, but I'm a little bit confused about best practises to achieve a good result.
First things first, API versioning. Over time my APIs will grow up and I want to keep them as smooth as possible. I've read this post: Best practices for API versioning? and I completely agree with it.
An excerpt of my routing strategy is:
/api/v1/ .. all sorts of controllers (api v1) ...
/api/v2/ .. (api v2) ..
/api/ .. controllers of the latest mainstream API
As a development strategy, I take advantage of JSON data formats, also to create new resources.
Another important aspect I'm afraid of is security: I cannot generate an authenticity token from the mobile APP, so I'm wondering how to protect the Rails API controllers.
Should I use standard HTTP authentication? Are there better ways to do that?
Last but not least, I'm trying to improve overall performances: remove unnecessary rack middlewares, inherit from ActionController::Metal and get rid of ActiveResource. Should I consider some pitfalls?
Any suggestion to build such a RESTful application will be appreciated.
You seems to be on right track, there are few things I want to mention:
Decide the input and output format. JSON is a faster choice but XML provides schema validation and more control. Chose depending on your need.
Use simple HTTP Basic authentication for security to start with. If you want more control, then introduces token based authentication such as OAUTH.
Make sure you use the plurals for the REST entities in URL. As plurals are good for a single or multiple entries fetch.
Decide about the synchronous and asynchronous nature of REST APIs. If an operation takes too long then make it asynchronous. Return a ref URL to user for polling as part of 202 Accepted response.
Hope it helps!
I'm trying to integrate a simple Rails app with a BPEL process but it's been hard since BPEL has few or maybe none support for RESTfull web services.
I've tried already using a HTTP binding but i'm not sure if I got what I want since the component moved to the internal side, and it's actually an external service.
So I have two questions:
I needed to write the xsd file to define the request and response xml structure. I searched and it seems there is no gem for doing this automatically. Is there any? Or even better, is there a gem that creates something like a wsdl file? I know this is for SOAP web services and in RESTful there is no such thing, but creating this files by hand is a pain in the ass. So I search something similar.
HTTP binding is the only way I found to call a RESTfull web service. Is there anything better? Has anyone been successful using it? Or code it in Java and use the Java adapter or something would be easier?
Any suggestion, even if not directly for my questions are appreciated. Thanks.
Also if there are some articles about it, links are welcome.
WashOut is a new SOAP server library and definitely worth checking out.
I building a website with Ruby on Rails framework.
The site will contain a flash application that will interact with the rails application using web service.
My partner builds the flash application and he told me that the flash application interacts through WSDL file.
I am new to web services. I would like to know how to create the WSDL file, and how to make the interaction between the rails application and the WSDL file.
If you believe that there are better alternatives than SOAP/WDSL, I would like to hear them too.
Thanks,
Oded
Have you Googled how to build web services in Ruby? Here are a few links that come up, all addressing exactly what you want to do:
http://www.tutorialspoint.com/ruby/ruby_web_services.htm
http://www.ibm.com/developerworks/opensource/library/os-ws-rubyrails/index.html
http://searchsoa.techtarget.com/tip/Web-services-with-Ruby-on-Rails
How about you take a look at some of those links, and come back to us if you have further questions.
I do have one elaboration:
My partner builds the flash
application and he told me that the
flash application interacts through
WSDL file.
It sounds like your partner has an incomplete understanding of how Flash can access remote data services. Using a SOAP Web Service with a WSDL is one method, for sure, and here is some documentation on that.
A Flex / Flash application can also make standard HTTP calls, sometimes called REST Web Services. In many cases, REST Web Services will return an XML Document, but that is not required. Any data, including simple text data, can be returned from a REST Web Service.
What many people prefer to do is to use an AMF Gateway with RemoteObject. AMF is a binary format so you'll get much smaller file size transferred back and forth than the alternatives. It also provides for automatic object translation between your server side objects and client side objects. This can be a time saver in development because you don't have to parse data to turn it into something Flex can use easily. RubyAMF is one Ruby implementation of AMF.
You'll be going through more pain than you need to by using WSDL.
Instead, I recommend creating a REST interface that returns json (or xml) -- you'll find in rails it will just work.
So you'll have things like:
/books # returns a list of books. Also do Searching here
/books/1 # return the detail of a book with ID of 1
Search for "REST Rails" and you'll get examples of controllers that will return JSON and XML depending on what the client requests.