Well, the title more or less says it all. I sort of understand what REST is - the use of existing HTTP procedures (POST, GET, etc.) to facilitate the creation/use of web services. I'm more confused on what defines what a web service is and how REST is actually used to make/expose a service.
For example, Twitter, from what I've read, is RESTful. What does that actually mean? How are the HTTP procedures invoked? When I write a tweet, how is REST involved, and how is it any different than simply using a server side language and storing that text data in a database or file?
This concept is also a bit vague to me but after looking at your question I decided to clarify it a bit more for myself.
please refer to this link in msdn and this.
Basically it seems that it is about using http methods (Get/Post/Delete) to identify the exposure of resources the application allows.
For example:
Say you have the URL :
http://Mysite.com/Videos/21
where 21 is an id of a video.
We can further define what methods are allowed to this url - GET for retrieval of the resource, POST for updating/ Creating, Delete for deleting.
Generally, it seems like an organized and clean way to expose your application resources and the operations that are supported on them with the use of http methods
You may want to start with this excellent introductionary writeup. It covers it all, from start to end.
A RESTful architecture provides a unique URL that defines each resource individually and infers through HTTP action verbs the appropriate action to do for the same URL.
The best way I can think to explain it is to think of each data model in your application as a unique resource, and REST helps route the requests without using a query string at the end of the url, e.g., instead of /posts/&q=1, you'd just use posts/1.
It's easier to understand through example. This would be the REST architecture enforce by Rails, but gives you a good idea of the context.
GET /tweets/1 ⇒ means that you want to get the tweet with the id of 1
GET /tweets/1/edit ⇒ means you want to go to the action edit that is associated with the tweet with an id of 1
PUT /tweets/1 ⇒ PUT says to update this tweet not fetch it
POST /tweets ⇒ POST says i got a new one, add it to the db, i cant give an id cuz i dont have one yet until i save it to the db
DELETE /tweets/1 ⇒ delete it from the DB
Resources are often nested though so in twitter it might be like
GET /users/1/jedschneider/1 ⇒ users have many tweets; get the user with id of jedschneider and its tweet id 1
The architecture for implementing REST will be unique to the application, with some apps supporting by default (like Rails).
You're struggling because there are two relatively different understandings of the term "REST". I've attempted to answer this earlier, but suffice to say: Twitter's API isn't RESTful in the strict sense, and neither is Facebook's.
sTodorov's answer shows the common misunderstanding that it's about using all four HTTP verbs, and assigning different URIs to resources (usually with documentation of what all the URIs are). So when Twitter is invoking REST they're merely doing just this, along with most other RESTful APIs.
But this so-called REST is no different than RPC, except that RPC (with IDLs or WSDLs) might introduce code generation facilities, at the cost of higher coupling.
REST is actually not RPC. It's an architecture for hypermedia based distributed systems, which might not fit the bill for everyone making an API. In the linked MSDN article, the hypermedia kicks in when they talk about <Bookmarks>http://contoso.com/bookmarkservice/skonnard</Bookmarks>, the section ends with this sentence:
These representations make is possible to navigate between different types of resources
which is the core principle that most RESTful APIs violate. The article doesn't state how to document a RESTful API and if it did so, it would be a lot clearer that clients would have to navigate links in order to do things (RESTful), and not be provided with a lot of URI templates (RPCish).
Related
I am trying to learn about RESTful services. In this tutorial I am watching, the instructor states the following:
REST services keeps things very defined between what is UI vs what is Services.
In general, what is the author implying here?
The services used within the UI are easy to spot vs. the rest of the UI?
Would the rest of the UI be CSS, HTML, and maybe some data stored in the local application?
Why does there need to be clear distinctions between the UI and services?
Do you know of an existing example of this I could take a look at to better visually understand?
It's probably impossible to explain exactly what a single sentence from a larger extract means without the context within which its embedded. But I'll have a go anyway. I suspect there was an element of hype involved - there's no guarantee that a Restful API is any more well-designed than a non-restful API and so there's really no guarantee that it will better enforce the separation between UI logic and business logic which we'd all love to see.
However, Rest's document centrism, its focus on statelessness, and its use of a uniform API do help in creating a clean layer between the UI (webapp or mobile app) and the server.
Other forms of service oriented architecture, such as RMI or SOAP, tend to be more focussed on providing a means of accessing a remote API as if it was local - in essence hiding the fact that a load of networking-stuff is happening to get that. The result is often a very fine-grained, although quite powerful, API which requires complex logic (business logic) embedded in the client application to use properly. These protocols can be quite chatty and network-inefficient because the focus is rarely on that data travelling over the network.
Restful APIs, which are centered around documents, tend to push UI designers in the direction of editing those documents - focussing the UIs on presentation and leaving logic either to the user or the backend service.
The uniform interface of Rest helps focus the API on working on documents - every resource is accessed in the same way, there's little leeway to add a custom response code which can be 'interpreted' in some way by the client. HTTP is a good protocol on which to build a Restful API for this reason - the major verbs are GET, PUT, POST and DELETE.
Similarly, the statelessness of Rest pushes the UI to focus on the data it has and how it should be, rather than on providing any kind of intermediate translation or caching layer to the user. The UI doesn't have any more information than the documents it has to present to the user - nice and simple.
The real core of your question, I guess, is "why should it be like that"? And the answer to that is that it keeps things simple and flexible. Presentation logic (e.g. what language or timezone or number format does the user care about) should not be mixed up with business logic (how many 'foo' widgets has the user bought in the past, do they really want a 'bar' widget now, because lots of people who bought 'foo' widgets want 'bar' ones too). Those two types of things have very different reasons to change and different types of people who are good at working with the underlying code.
I am developing a SOAP interface and am having trouble deciding what to name the endpoint address.
Options:
- {soap,api,service,???}.foo.com.au
- www.foo.com.au/{soap,api,service,???}
What are the typical names that a SOAP service gets?
I would use www.foo.com.au/soap, mostly because it's an easy way to tell people that it's a SOAP service, and if you want to add a REST service later, you can use www.foo.com.au/rest
Keep in mind, in practice, all solutions are technically equivalent. The benefits of one naming system over another are only at the ease or understanding what the URLs are about (for humans), or maintainability, really. So, if you are searching for a standard we can tell, at best:
If you have a big company with lots of applications, go for the http://api.company.com/application/rest and/or http://api.company.com/application/soap approach
Reason: you can separate, right from the start (networkwise) the web service servers (http://api.srv.com/app) from the human web browsing servers (http://www.srv.com/app).
All applications have one big root "meeting" point (the root URL api.company.com), so if anyone wonders what is company-wide available, just check http://api.company.com and it can list all services available.
If your setup is not that big, it is probably not worth the trouble, so don't fear using the www.. But keep in mind it's best to use at least a different context, such as api/, so that anyone knows right off the bat a service URL is about a web service(!): http://www.company.com/application/api/rest / http://www.company.com/application/api/soap
Note: It's also common to use service, although api seems to be somewhat better descriptive (api.something.com leaves no doubt about what that page is about).
Some examples (as you can see, there is really no global standard):
Google's search API: http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=test
Twitter's search API: http://search.twitter.com/search.json?q=w00t
Facebook' Graph API: http://graph.facebook.com
Facebook' Dialog API: http://www.facebook.com/dialog (see, no standard even within facebook!)
Weather Gov SOAP forecast: http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Buy many seem to keep the good ol' company-wide APIs "meeting points":
http://developers.google.com
http://developers.facebook.com
http://dev.twitter.com
I am in the process of developing a rich internet web application that communicates to a (Java) back-end via web services. I have prototyped a user interface in both Flex/Flash and GWT/Javascript and have noticed that these RIA platforms tend to favor an RPC-style method of back-end communication (AMF for Flex and GWT-RPC for GWT).
In my case, the server also needs to provide web services other clients that I do not author. Because of this, I am leaning towards standards-based web services (e.g. SOAP and REST). I am convinced that the RIA must use the same web service we provide for others. I "get" SOAP because it models the RPC style I am familiar with from experience. I am new to REST, but have prototyped a REST back-end using CXF/Jackson. At this time, however, my REST API still feels like an RPC-style API and I realize it's because I am having trouble getting my head around the idea of HATEOAS.
I have read Roy T. Fieldings helpful blog post about 10 times and I think I am beginning to see the light. For example, it is clear to me that if I were to include links to various state transitions along with my resource I could really reduce the amount of coupling between my client and server. My client could just render buttons that provide the user with access to the legal operations that can be performed on the displayed entity at that time.
But does loose coupling between a RIA and its server application matter?
By their very nature, RIAs are pretty tightly coupled with the server data model. Out of the box they presuppose many things. I am guessing that is why they also prefer an RPC-style application protocol...because loose coupling is not a design goal. But I am beginning to realize that if we took HATEOAS seriously, we could write a much more generic RIA client that would make VERY few assumptions about the data model and operations that can be performed. That could reduce the amount of effort to maintain the client through changes in the back-end, but does this make sense? does the benefit outweigh the cost?
p.s. - Two more details -- This application has an extremely complex, deeply nested data model. Also, I could not care less if somebody tells me we are not a 100% pure REST web-app.
It's an excellent philosophical question. My general response is some coupling should be expected.
Let me explain more. While it's possible to conceive of a fully generic application interface that just exposes the model in a human-usable way, it's actually incredibly difficult to write such a piece of software except for truly miniscule domains (e.g., filling a record that will be used to populate a DB where all the fields are picked from finite simple enumerations). If your application doesn't fit that model, you're going to have to have something in there that is specific to the app. If you do that in a “generic” way, you'll be downloading a complex description of what your generic client app is supposed to do, and that description will itself start to feel more and more like a programming language. Now you're back to square one, except with a (probably badly-designed) new domain-specific language in the mix as well. You might as well cut to the chase and accept that going wholly generic isn't worthwhile.
But that's not to say that you shouldn't take care to think carefully about what resources you expose, what verbs apply to those operations, and how users' software will discover those resources. Following REST and HATEOAS there will help a lot (and it helps if you've got a clear idea about what the application's underlying abstract model is; you should aim to expose that in a natural way).
Given that the GWT app is served by HTTP, having it tightly coupled with the server is not violating HATEOAS. It's" code on demand".
Google, Twitter and Facebook all use specific APIs for their app, different from the one exposed to third parties (Twitter has recently moved to using their public API for their web app, but it wasn't originally the case). Google said they had no plan to move G+ over to its public API, because it allows them to experiment and make breaking changes without breaking third parties.
RESTful and document/message-style seem to be two trends to implement web services nowadays in general. By this, I mean REST vs SOAP, and document-style vs RPC-style.
My question is how compatible REST is with document-style web services. From my limited knowledge of REST, it is utilizing http GET/POST/PUT/DELETE verbs to perform CRUD-like operations on remote resources denoted by URLs, which lends it into a more "chatty" and remote-method like style, aka RPC style. On the other hand, document-style web services emphasize on coarse-grained calls, i.e. sending up a batch like request document with complex information, and expecting a response document back also with complex information. I cannot see how it can be accomplished nicely with REST, without declaring only one resource for "Response" and using POST verb all the time (which will defeat the purpose of REST).
As I am new in both document-style and RESTful web services, please excuse me for, and kindly point out, any ignorance in above assumptions. Thanks!
Your understanding of REST is misguided. This is not surprising nor your fault. There is far, far more mis-information about REST floating around on the internet than there is valid information.
REST is far more suited to the coarse-grain document style type of distributed interface than it is for a data oriented CRUD interface. Although there are similarities between CRUD operations and the HTTP GET/PUT/POST/DELETE there are subtle differences that are very significant to the architecture of your application.
I don't think you mean REST over SOAP. It is possible to do REST over SOAP, but to my knowledge nobody does it, and I have never seen an article talking about it.
SOAP is usually used for "Web Services" and REST is usually done over HTTP.
REST is really meant to be used with documents as long as you consider your document a resource.
GET allows you to retrieve the document. Obviously.
POST allows you to create a document. No need for your API to require the full content of the document to create it. It is up to you to decide what is required to actually create the document.
PUT allows to modify the document. Again, no need to force the client to send the whole document each time he wants to save. Your API may support delta updates sent through PUT requests.
DELETE obviously deletes the document. Again, you can design your API so that deletes does not actually destroy every bits of the document. You can create a system similar to a recycle bin.
What is nice with REST and working with documents is that the server response contains every information needed to understand the response. So if a new resource is created, you should send its location, same if a resource is moved, etc. All you have to document is the data types that will be used (XML formats, JSON, etc.)
Standard HTTP methods are just there because their behaviour is already defined and allow clients to easily discover your API as long as they know the URI.
I have 2 websites(www.mysite1.com and myweb2.com, both sites are in ASP.NET with SQL server as backend ) and i want to pass data from one site to another.Now i am confused whether to use a web service or a form posting (from mysite1 to a page in myweb2)
Can any one tell me the Pros and Cons of both ?
By web service I assume you mean SOAP based web service?
Anyway both are equal with few advantages. Posting is more lightweight, while SOAP is standardized (sort of). I would go with more restful approach, because I think SOAP is too much overhead for simple tasks while not giving much of advantage.
Webservices are SOAP messages (the SOAP protocol uses XML to pass messages back and forth), so your server on both ends must understand SOAP and whatever extensions you want to talk about between them, and they probably (but don't have to) be able to grok WMDL files (that "explains" the various services endpoints and remote functionality available). Usually we call this the SOAP / WS-* stack, with emphasis on 'stack' as there's a few bits of software that needs to be available, and the more complex the SOAP calls, the more of this stack needs to be available and maintained.
Using POST, on the other hand, is mostly associated with RESTful behaviours, and as an example of a protocol of such, look to HTTP. Inside the POST you can of course post complex XML, but people tend to use plain POST to simplify the calling, and use HTTP responses as replies. You don't need any extra software, probably, as most if not all webkits has got HTTP support. My own bias leans towards REST, in case you wonder. Through using HATEOAS you can create really good infrastructure for self-aware systems that can modify themselves with load and availability in real-time as opposed to the SOAP way, and this lies at the centre of the argument for it; HTTP was designed for large distributed networks in mind, dealing with performance and stability. SOAP tends to be a one-stop if-it-breaks-you're-stuffed kinda thing. (Again, remeber my bias. I've written about this a lot on my blog, especially the architecture side and the impact of SOA vs. ROA. :)
There's a great debate as to which is "better", to which I can only say "it depends completely on what you want to do, how you prefer to do it, what you need it to do, your environment, your experience, the position of the sun and the moon(s), and the mood my cat is in." Eh, meaning, a lot.
I'm all for a healthy debate about this, but I tend to think that SOAP is a reinvention; SOAP is an envelope with a header and body, and if that sounds familiar, it is exactly how HTML was designed, a fact very few people tend to see. HTTP as just a protocol for shifting stuff around is well understood and extremely well supported, and SOAP uses it to shift their XML envelopes around. Is there a real difference between shifting SOAP and HTML around? Well, yes, the big difference is that SOAP reinvents all the niceties of HTTP (caching, addressability, state, scaling), and then use HTTP only for delivering the message and nothing else and let the stack itself have to deal with those niceities mentioned earlier. So, a lot of the goodness of HTTP is ignored and recreated in another layer (hence, you need a SOAP stack to deal with it), which to me seems wasteful, ignorant and adding complexity.
Next up is what you want to do. For really complex things, there's lots in the webservices stack of standards (I think it's about 1200 pages combined these days) that could help you out, but if your needs are more modest (ie. not that crazy about seriously complex security, for example) a simple POST (or GET) of a request and an envelope back with results might be good enough. Results in HTTP is, as you probably know, HTTP content-type, so lots is already supported but you can create your own, for example application/xml+myformat (or more correctly, application/x-xml+myformat if I remember correctly). Get the request, if it's a response code 200, and parse.
Both will work. One is heavy (WS-* stack) depending on what your needs are, the other is more lightweight and already supported. The rest is glue, as they say.
I would say the webservice is definitely the best choice. A few pro's:
If in the future you need to add another website, your infrastructure (the webservice) is already there
Cross-site form posting might give you problems when using cookies or
might trigger browser privacy restrictions
If you use form posting you have to
write the same code over and over
again, while with using the
webservice you write the code once,
then use it at multiple locations.
Easier to maintain, less code to
write.
Maintainability (this is related to
the above point) ofcourse, all the
code relevant to exchanging data is
all at one location (your webservice)
There's probably even more. Like design time support/code completion.
From my little experience I'd say that you'd be best using a web service since you can see the methods and structure of the service in your code, once you've created it at the recieving end that is.
Also using the form posting methos would eman you have to fake form submissions which isn't as neat as making a web service call.
Your third way would be to get the databases talking, though I'm guessing they're disparate and can't 'see' each other?
I would suggest a web service (or WCF). As Beanie said, with a service you are able to see the methods and types of the service (that you expose), which would make for much easier and cleaner moving of data.
I agree with AlexanderJohannesen that it is debatable whether SOAP webservices or RESTful apis are better, however if both sites are under your control and done with asp.net, definitely go with SOAP webservices. The tools that Visual Studio provides for creating and consuming webservices are just great, it won't take you more than a few minutes to create the link between the two sites.
In the site you want to receive communication create the web service by selecting add item in VS. Select web service and name it appropriately. Then just create a method with the logic you want to implement and add the attribute [WebMethod], eg.
[WebMethod]
public void AddComment(int UserId, string Comment) {
// do stuff
}
Deploy this on your test server, say tst.myweb2.com.
Now on the consuming side (www.myweb1.com), select Add Web Reference, point the url to the address of the webservice we just created, give it a name and click Add refence. You have a proxy class that you can call just like a local class. Easy as pie.