I was trying to put the difference between websites and web services (irrespective of RPC based or RESTful) development in words. Am I right is saying when a client is another software (assuming browser is just a tool for the original client) and producer is responding in XML (assuming this is the standard for data transportation) comes under web services (programmable web) otherwise its a website for humans?
Thanks
-Abidi
Yes. One could further precise that bots and crawlers are a secondary phenomenon where software attempts to mimic human behaviour. So that your high level distinction still stands.
The huge difference is that web sites have a double role
provide information
present information
Whereas for web services, there is no concept of presentation. You will find this same distinction in their respective expression languages: whereas HTML cumulates both information tagging and presentation directives, xml is only about information identification, organisation, transformation and organisation.
Historically XML followed in the wake of HTML when people figured out that there were better ways to access information exposed by web sites than just ripping their not well formed html pages more or less aping humans; whilst at the same time everybody knew that neither CORBA nor RPC could fill the need for B2B communication because of their unability to be routed through a WAN.
Hence then, SOAP, all the OASIS standards and only later REST services, still preferred for devices too 'light' to accommodate full fledged SOAP stacks.
Something like that. Of course the client calling the "web service" may be the browser itself. I'd say that the difference is that a web site returns content that is meant to be consumed by human beings while a web service returns content meant to be consumed by another program. In the latter case it doesn't have to be encoded as XML; it can be anything. It's tough to make a good distinction between "web site" and "web service" on the basis of the type of content returned, because there is plenty of content that can be consumed equally well by a human being and a program. A service might return a PDF of a customer statement, for example, and could be used directly by the customer and also by a bill-printing program.
Maybe a better definition is to say that a "web site" is a collection of "web services," some of which may return HTML pages and some of which may return other types of data.
Related
I have a situation where two components are being designed that have some similar presentation requirements, but have been built using different technology stacks (one is java and the other is .net). For one feature, the developers are propsing using a web service that returns HTML so that both components can re-use the same display logic. I have been told that it is a bad practice to use a web service in this fashion, and that a web service should focus only on data.
In terms of web-service or SOA best practrices, should you return HTML from a web service?
If it's actually a web service (i.e. meant to be called by scripts), HTML is a bad idea, as you'll have a difficult time handling error situations.
A well-designed XML or JSON answer is probably the way to go these days.
Hi I am a college student and a newbie in web service. I did some research about web services however, and I am going to add a web service to some websites in my institute to integrate data from them. Since they are various CMS (like I mentioned in the title), I need info about them.
What I ask about is the features, advantages and disadvantages (and maybe the requirements needed) about web services in each of the CMS (DSpace, Moodle, EPrints, WordPress, Joomla, Open Journal System)... for example, if I’m not mistaken, WordPress provides web services like RSS. Do the others provide it too?
Sorry for the vague question, but I really have no idea - especially about DSpace, Moodle, OJS and EPrints - any information would be helpful.
Web services (which can be SOAP or REST based), you may call them also APIs, have little to do with RSS feeds (from my point of view).
Web services generally will provide an interface and exchange data. How they are implemented behind the interface they expose, it's not relevant to the client.
Wikipedia defines web services as a "software system designed to support interoperable machine-to-machine interaction over a network." As implementation they are more complex than RSS feeds and are usually used to integrate business applications (like connecting an ERP with a CRM system).
On the RSS part, all decent CMS should have RSS available (in a form or another) generally for sharing content.
From my knowledge Joomla! don't have any web services implementation (Joomla! is working on a draft document as we speak). Wordpress has XML-RPC Support.
So it's kind of important to understand what does "data" mean. Do you strictly refer to content (like articles, blog posts) or do you want to exchange other data as well (for example user data or other data stored in the CMS tables).
So to kind of answer your question, to integrate articles from all CMS probably using RSS feeds will be enough.
DSpace started life as an institutional repository software and is trending toward a more general digital asset manager. It really emphasizes preservation (checksums, auditing, item level versioning) and descriptive information of the content it handles. It generally handles any file equally well: a WARC, MPEG, TIFF, MS Office, etc., but it isn't really focused on web publishing of that content, but simply online access to and download of it.
There's an independent REST API for it, and it comes with SWORD support. Content can be published in an RSS feed - I don't know if DSpace has any functionality for importing content that way.
My first instinct is to say this isn't what you're looking for. DSpace is focused on long-term retention, organization and access to content, not so much quick (or automated) aggregation of content from online sources.
We have some XML restful services implemented in MVC (C#). Their overall look and feel is very similar to http://www.zendesk.com/api.
Now we need to accept some files uploaded.
The services are intended for consumption from PHP / Python / ruby and other popular web development languages.
How should we do it right? multipart/form-data? or just read post body?
I'm concerned about the ease of use from mentioned languages and popular web development frameworks. Unfortunately, i don't have anyone to ask on consumer side.
I'm also concerned about memory consumption. As i understand, multipart/form-data will be converted by MVC / ASP.NET to HttpPostedFileClass which caches itself on the web server disk. But plain POST won't, so it will consume IIS memory?
Maybe there are other notable options to consider? What do you think?
This sounds like a very standard content management application, which REST excels at.
The most straightforward way would be to PUT to a resource whose name is a single file, say http://www.example.com/myfileserver/folder1/folder2/myfile Then you GET the same resource to download the file, PUT to update the file, and DELETE to get rid of it.
In REST, the HTTP operation verb is crucial: POST is designed to add a new resource to the server when you don't know the resource name and the server assigns it. In your case you use PUT, which creates or updates a resource for which the name is known beforehand.
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers
I am little bit confused about what really a web service is. You say Amazone web services,etc like that, they offer information. So what is the requirement to be a web url to be a web service ? Let's say I am not much familiar with web development, how could you explain it to me ? But I can get it if you point some ways.
And also little about SOAP and REST basically for someone really new
What is a web service
It is many things. In programming, in generally refers to a web page, that can be called from an application (be it another web page, or desktop app), and the caller will pass in data to it, or receive data from it.
In this sense, it's basically like a 'method' or 'function' in a normal programming language; except you're calling it over the internet.
SOAP
A message format. As discussed above, a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.
REST
REST is the means of implementing an interface to your application but, implementing access control, and other such things, specifically with HTTP Response codes. So you will get a 401: Denied (I think that's the right code), if you don't have access. There are other types of response codes that are useful. It also makes use of other HTTP commands like PUT/HEAD/OPTIONS.
The W3C defines a Web Service as (quoting) :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network. It has an interface described
in a machine-processable format
(specifically WSDL). Other systems
interact with the Web service in a
manner prescribed by its description
using SOAP-messages, typically
conveyed using HTTP with an XML
serialization in conjunction with
other Web-related standards.
That definition is maybe a bit too restrictive, considering how that term is used nowadays -- I'd probably go with just the first part of that definition, which is quite generalist :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network.
Wikipedia also has some interesting definitions, like :
In common usage the term refers to
clients and servers that communicate
over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
From what I've seen :
A couple of years ago, when we said "web service", we generally meant "SOAP, WSDL, ..."
Now, when we say "web service", we often mean "whatever allows to call something on another server, be it SOAP, REST, ..."
A Web-Service can be considered as a set of methods that enables communication amongst applications irrespective of the application's coding language or framework.
http://acharyashri.com/blog/WebServices.html
Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over—how can you go about providing that remote method what it needs in order to get instantiated?
When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.
Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. It's just an interface to describe a web service.