I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.
Related
Introduction
We are in the beggining of the development of a new web client for our current web application.
And we will take the chance to build a REST WebApi to access our assets (to be consumed by third parties, and also our new web client)
We're considering OAuth, Service Quotes, Application permisions, etc for the WebAPI
We want to "eat our own dogfood", so the new webclient must use the webapi...
Important: The webApi and the webClient will be hosted in the same server
Questions
A simple use case would be "Get the menu page links"
For the web client which of these 2 approach would you choose?
a) Generate an html with a Js webApiCall inside it to be called from client web browser to get the available menu links for the user. = (2 round trips: 1 for the html/aspx + 1 for the api call MenuGetAvailableItems)
b) Generate an html with the data menu links already populated (webApi MenuGetAvailableItems consumed internally in server side) = (1 round trip for html/aspx + an API internal call..)
If you choose option 1B, Is it possible to avoid the http overhead by consuming the api from the same server and mantain the security, Quotes, etc? I mean, can we use some WCF mechanism or other to communicate this 2 webs instead of making an http call to localhost...?
Thanks for your comments
Q 1
regarding option a - I would avoid calling Web API from the web page, you will start to run into problems with CORS. Also, what if you want to use authentication to access the Web API service, how are you going to send a user name and password from the web page!
regarding option b - you certainly can consume the web api service from inside your web app.
Q 2
I don't understand your what you are asking.
If your primary purpose for building a web service is to allow a third party to interact with you, you are going to want build just the services that need to be exposed.
In general, "eating your own dogfood" might not be the best reason to use Web API where standard calls to the database would be more appropriate. You going to have two applications running, when all you really needed was a data tier in the web app.
It sounds like you are going to end up with a sprawling Web API app that will need new services every time you want to add something to your site.
Is it possible to create a website (hosted locally on my machine is fine for now) using a WCF Service Application?
By "web site" I mean allow an HTTP call from a web browser to my service and have the service return an HTML page that the browser can then render/display.
I am doing something very similar using a WCF based REST service. I have a WCF service that is accessed only from a web browser to download images. If you browse to 'http://www.MyFooImageService.com/100', it will lookup from the database an image with ID 100 and serve it up to the user. I use it to serve images from WCF service for the purpose of sending (user defined) emails with embedded images.
I used this guide with great results: RESTFUL WCF Service Step-ByStep. Check it out and see if a REST based WCF service is what you are looking for.
No, it doesn't quite work like that. WCF applications are service applications. There is no GUI interface or web interface or any kind of interface at all.
What you do is you create a WCF service that does some sort of function. Lets say you create a method called StoreName that stores your name into a database. Keep it simple. WCF services can be hosted in a variety of ways, depending on how you plan to use it. But to keep it simple, lets say you host the application using IIS.
Now this WCF application has no interface for interacting with it. You need to create an ASP.NET application (or it can be PHP, or jQuery if you prefer). It might have a text box and a submit button. Once the submit button is pushed, the ASP.NET application (or jQuery or PHP) makes an ajax call to your WCF service, passing it in the name as a POST parameter. The WCF service then does the work of storing it in the database. Execution then returns back to your web application.
This is a general overview of how this works. I hope it helps!
A website involves:
1) A user requesting HTML from somewhere
You can proxy pass a simple HTTP Get request to a WCF service hosted in a console app (or hosted in IIS), and configure it to return an HTTP request of content type text/html. Then the user would see a website appear in the browser.
But WCF is not a good fit for this. Especially if it's a simple HTML page. Others have said ASP.NET is better for this. And that's true. But node.js or PHP or pretty much anything that isn't .NET is MUCH better for this.
2) A user uses the web page to interact with server processes
This involves a user clicking a button or moving a mouse, or anything, and then that results in the web page (actually a web app at this point) making AJAX requests to one, or several server(s).
WCF is quite a good fit for this.
This is really basic.I want to implement a RESTful web API.
Now I know you can write custom applications and scripts to integrate with the API.
What I need to know:
In what languages can you write this API? C#, Java, php?
When building/programming a program that implements this API, is this the client and the software that issued the API the server? (eg. Dropbox would be the server and the custom app that integrates with the Dropbox API is the Client?
Thank you.
A REST API can be built in any programming language that allows you to handle HTTP requests (or can be attached to a Web server as a handler for requests). The two methods I've been using:
Stand-alone Windows service implementing a REST service using WCF
WEB server Apache + PHP
You are correct about the terminology. A program consuming a service is called the client, a program providing a service is called the server (while actually in the PHP approach, Apache would be the server as it is taking the request and having the script handle it).
Additional nitpicking: JQuery is not a language, but a framework to help you use some JavaScript features more easily.
On your comment Recap:
Close :-) The Client transfers JSON/XML/whatever to a server using HTTP requests. The Client can be written in any language that can perform HTTP requests.
On the server side, there needs to be some application that handles the HTTP requests (service), also written in any language, as long as it "speaks" HTTP.
The API is the definition of which operations are possible, for example, adding user accounts, getting the current time, etc. (this is what you define - what do you want your service to do?).
The JSON/XML/whatever that you transfer is the workload, the parameters for the API call. For example, if you want to add a new user to your system, the workload could be the new user name, the real name, the eMail address and some other details about the user. If the API call returns the current server time, you might not need any parameters at all, but you get back JSON/XML/whatever from the service.
The actual call being made is determined by the URL you call. For example, the URL for adding a user could be http://localhost/myrestservice/adduser and you'd perform a POST request against that URL with the required workload. For the time example, the URL could be http://localhost/myrestservice/getservertime and you'd perform a GET request against that URL.
I suggest that you read about how REST services actually work before you start, as I see some question marks on your face ;-)
Short:
API = available operations (=> URLs)
Parameters to API calls = JSON/XML/Plain Text/whatever
Client = calls the service through HTTP
Service = handles the calls, replies to client in response to HTTP requests
If you are a php programmer and familiar with Codeigniter framework then go here : Working with RESTful Services in CodeIgniter.
visit also : Rest Tutorial
First of all, you should begin with learning what is a RESTful API.
http://en.wikipedia.org/wiki/Representational_state_transfer
http://www.restapitutorial.com/
http://rest.elkstein.org/
In what languages can you write this API? C#, Java, php, jQuery?
You can write an API in any language. What can help is the framework you'd be using. JQuery is not a language, but a framework for integrating Javascript application in every web browser, so it won't help.
I'd advice you to use a microframework to write your first RESTful API, because they usually are easy to use and help focus on the important (bottle/flask in python, express in javascript, silex in php, spark in java or nina in C#)
When building/programming a program that implements this API, is this the client and the software that issued the API the server? (eg. Dropbox would be the server and the custom app that integrates with the Dropbox API is the Client?
You're right, the server is providing you the service, hence the API. The client is user to that API, and implementing it into something useful.
As most of the people stated already, you can do this in just about any language.
Might I suggest that you look into NodeJS? If so, check out Restify: http://mcavage.github.io/node-restify/
There's a nice community behind NodeJS and I think it's quite open to newcomers. Just try not to pick up bad habits from JavaScript pitfalls. If you're new to programming, I'd suggest reading some intro book.
good luck!
I have an web application built using RESTful services (JAX-RS).
There are REST calls, and simple JSPs with js files to handle data.
Now I want to implement authentication and authorization in service. What I did earlier was to implement simple filter and inside each service check for #HttpRequestContext for if session has user object. Since it I want to expose service to say, external webapp, I will have to hard code system as there is no standard.
I feel this is not good design. Is there a design pattern to solve this common issue ?
I am new to ASP.NET Web API. Can anyone please tell me
Why we need Web API?
How it differs from rest full api from MVC ?
When to use MVC4 web api ?
What is restful api in MVC
WebAPI is based on MVC, but has some subtle differences. You need to understand that WebAPI is a separate thing from MVC, and does not require MVC. You can install WebAPI separately, and you can uninstall it from the default MVC templates.
It's true, MS could have built WebAPI directly into the MVC Controllers, but they chose to keep API Controllers separate from MVC Controllers because they really are different ways of dealing with requests and responses.
Examples of things you can do in WebAPI that you can't (or at least not as easily) in MVC include:
Content Negotiation
This allows the calling client to choose the format that data will be returned in, such as XML or JSON.
OData support
This allows the caller to "filter" results on the server without the service method having to specifically support it. For instance, if you want to sort the results by first name, then this can be done simply by specifying OData query parameters
WebAPI provides a lot of power for dealing with data result sets. MVC does not provide that kind of functionality.
You would tend to use WebAPI for things like Ajax requests, or web service based requests that do not require the complexity of WCF.
RESTful API's are not specific to MVC or WebAPI. They're simply a philosophy for how you design your HTTP requests in a service. There's a lot to it really, but I won't go into it.
WCF team merged at Microsoft with MVC team. WCF is not going away, but for simple RESTFUL service call, the MVC Controller were a match made in heaven, and the modification to it allowed for a very easy Web API.
While many of us feel WCF is relatively easy, there are many who fear it and/or don't have/take time to learn it, thus they a. still use ASMX, b. still never adopted services, or NOW with Web API, are c. Very excited that they can very easily get up and running with restful web services.
So really it is a matter of comfort level, adaptation, ability to change and the Web API does have its place. It cannot replace WCF as WCF has advanced configurations with all the bindings and ability to do SOAP and not just REST, which many applications still NEED to have SOAP protocol.
MVC is optimized to serve information to a web browser client. If your client is something else, Web API will make your life easier over the long term.
Web API is a from the ground up re-write of the web stack. At the core it is much cleaner and more flexible than the 12 year old infrastructure that MVC is built on top of. Web API does not yet have the same level of tooling, add-ons, plugins as MVC, but that will come.