Are all web services automagically restful web services? - web-services

Are all web services through HTTP and not SOAP automagically restful web services?
I have been hearing the term "Restful web services" everywhere.. but ain't it simply a plain old "web service that uses http".
I have a url at A.php and clients request data from me like this: A.php?parameters_supplied_here_etc_etc
And since the url has a length limit, for longer messages they will send a POST request with the parameters to A.php
Basically if anyone wants to talk to my server/database, it goes through the page at A.php
So can I say that it's a restful web service??


There are at least two types of web services around:
SOAP web services - using XML Schema to strictly define XML messages, typically, but not necessarily using HTTP as a transport protocol. Reliable and standardized, they've been around for quite some time, although sometimes considered heavyweight.
RESTful web services - less rigid, using plain HTTP protocol, taking advantage of built-in GET/POST/PUT/DELETE methods to perform CRUD operation on resources. Content negotiation (typically XML or JSON), redirects (Location header) and user-friendly URLs make RESTful web serives getting more attention.
These are two different communication protocols, you can migrate one into another, but no automatic conversion ever happens.


No, because to be a REST service, it needs to fulfil certain criteria. See wikipedia
There is a quote there which might answer your question better than I can:
SOAP RPC contrast
SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP POST verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary.[8] Examples of doing so may include the addition of methods such as getNewUsersSince(Date date), savePurchaseOrder(string customerLogon, string password, ...).


The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. Other (such as SOAP) are more RPC-like. SOAP refers to Simple Object Access Protocol and is usually overlaid onto the HTTP POST. SOAP has recently been stretched in some REST-like directions.


One of the cornerstones of "REST" architectural style is using HTTP to its full potential (GET, HEAD, PUT, POST, DELETE, content-type, etags, cache control, etc) instead of as a tunnel. If you do just that, you already win a lot, and I think you should feel entitled to call your service "REST Inspired" or something. From there you can use all the existing building blocks of HTTP infrastructure to your advantage, instead of having to work against them.
It's often tempting to come up with your own RPC or CRUD protocol over HTTP, and reinvent the wheel. The result is usually quite contrary to REST principles.


Are all web services automagically restful web services?
No there is no magic. You have SOAP and other protocols which are not RESTful.


If all your request go through the same URI then this is a clear sign that you're not using URIs to identify the individual resources of your system, so - no.
That being said; there are more constraints such as uniform interfaces, or hypermedia-driven.

Related

Types of web API's (web services)

Recently i have been doing some research about web services.
What i understand so far is that a web service is basically an API that communicates over HTTP.
There are Different kinds of web services:
SOAP web services (api that uses SOAP)
RESTful web services (api that uses The REST)
During my research those were the only ones mentioned except for one site. There they also mentioned:
XML-RPC
JSON-RPC
Are those also web services? And why aren't they mentioned?
If i said something wrong feel free to correct me.
Types of Web Services There are mainly two types of web services. SOAP
web services. RESTful web services.
-source: http://sfdcsrini.blogspot.com/2015/09/what-is-web-service-and-what-are.html

Broadly speaking, you're correct that there are two types of web service, but it's not SOAP vs. REST. It's RPC vs. ReST. There are other types of 'web' service which don't interact over HTTP, but they tend to be for specialist use cases these days so lets ignore them for now.
An RPC service is one where the API models some kind of abstract 'object' on which some defined set of 'methods' can be called - hence the name Remote Procedure Call. Any object defined in the API can have an arbitrary set of methods defined against them and HTTP is typically just used as a transport mechanism, with all the information required for the call to happen (object identifier, method name, call parameters) being serialised into a document which is transferred to the remote end via a POST operation and all objects are accessed via the same URI. Sometimes, query parameters on the URI are used to identify the object and/or method. SOAP and XML-RPC are both types of RPC implementation styles and are similar but not the same. JSON-RPC is another RPC mechanism, it just uses JSON to encode the RPC call rather than the more verbose XML.
ReST, on the other hand, is a resource oriented API style. In a ReSTful API the application communicates with 'resources' by transferring representations (i.e. serialised document formats) back and forth. Each resource has a consistent & well defined API and a unique address, called a URI. HTTP can then be used not just as a transport mechanism but, more importantly, also as an implementation of the API. So, the only way to interact with a resource in a ReSTful API is via one of the well-known HTTP methods - GET / PUT / POST / DELETE / PATCH. Not every API endpoint will implement every method but no endpoint will implement anything other than those methods.
The most important difference between the ReSTful approach and the RPC approach is what the data transferred means. In a ReSTful API the documents transferred represent the resource which the application wishes to manipulate whereas in an RPC the document transferred represents the method call which the caller wishes to make (or its response).

Two Type of API (Application Program Interface) was avilable.
That Was,
1)SOAP - Simple Object Access Protocol.
2)REST - Representational
State Transfer.

Why/How SOAP is Stateful?

I don't have any reference to give here to show my research (because none of the links are to the point) and even Google doesn't have an exact answer. Everyone says web service is stateful but that's confusing. By principle, I believe, SOAP is stateful and REST is stateless. So, Why/How SOAP is stateful ?

Basically Stateful means that server stores information about the client and uses that information over a series of requests. So performing one request is dependant upon the state of some other request (e.g. previous). Implementing this is possible with http protocols.
So you can have stateful or stateless SOAP - it's only a matter of how you design it.
Also please note that comparing SOAP and REST is not really correct.
The first one is basically Protocol (or at least it's trying to be) and REST is just a architecture pattern/style.
I know this is not exactly answering your question but please take a look at this link: SOAP vs REST (differences)
It's extremely well written and can help you understand those technologies a bit better.

First off, SOAP is protocol. In other way we have services like REST, WSDL, WCF and many more. SOAP can be used as protocol in all kind of services. This mean, soap provide mechanism to pass data between client and server.
By design and main purpose SOAP is data protocl to be use between server and clients. Server(service) save, preserve and response data.
Soap as data can be used in both variants in service - stateful or stateless.
By default soap service is stateless. For example WSDL soap service is stateless. Simple WebAPI, REST. They are all stateless.
WCF - Single Instance is stateful.
WCF - Per call is stateless.
Being stateful is not one of SOAP protocol principles or ideas behind it. Service can be stateful or stateless.

using http status code in RESTful services

I am looking for a good meaningful discussion of why people feel like it is a good idea that RESTful web services hijack HTTP response codes and assign meanings to them in the context of the given API. My intuition revolts against it: it feels that HTTP is serving as the transport layer protocol here and why would I leak my API concepts into the transport layer? Yes, I understand that HTTP is application layer in the 27 layer diagram, but layering is relative. For my API HTTP is a transport.
Now people say that otherwise error handling can't be standardized. But REST doesn't really standardize it either. We can feel good about 401 and 404 messages being somewhat intuitive, but that's bout it. What it really does is makes it harder to differentiate between and API error and API server not being there/client not pointing to the right place etc.

Which of those scenarios you think would bring better outcomes:
Re-Using HTTP status codes like 200-OK, 404-Not found, 500-Error, etc for an API layer to mean similar responses that are mostly guaranteed to be used in a standard way across all RESTful API vendors
OR
API vendors return 200-OK, and the message body contains custom response envelopes or bodies to mean similar things (like Not Found, and Error)
First scenario allows also for developing standard libraries to communicate with those APIs where the second scenario means every API is a unique case and things like error handling, caching, etc cannot be done in a standard way.

How non-SOAP web service clients knows about the structure of the response?

How non-SOAP (REST WS, HTTP WS) web service clients knows about the structure of the response?
I mean, is there a formal way?

No.
The "provider" of the service needs to provide some form of documentation for that service - what parameters are possible, what the response will look like.
This is one of the major drawbacks of non-SOAP services...
There are a few initiatives like WADL (Web Application Description Language) - but those are far from widely accepted and thus not really a valid alternative to WSDL.
Microsoft has also extended REST to include metadata used in WCF REST and the WCF Data Services to allow .NET client-side proxies that "know" about the REST calls and the parameters - but again, that's not really an industry standard that everyone follows.

What are WSDL, SOAP and REST?

What is WSDL? How is it related to SOAP? Where does REST fit in all of that?

A WSDL is an XML document that describes a web service. It actually stands for Web Services Description Language.
SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.
REST is an architectural style of networked systems and stands for Representational State Transfer. It's not a standard itself, but does use standards such as HTTP, URL, XML, etc.

Example: In a simple terms if you have a web service of calculator.
WSDL: WSDL tells about the functions that you can implement or exposed to the client. For example: add, delete, subtract and so on.
SOAP: Where as using SOAP you actually perform actions like doDelete(), doSubtract(), doAdd(). So SOAP and WSDL are apples and oranges. We should not compare them. They both have their own different functionality.
Why we use SOAP and WSDL: For platform independent data exchange.
EDIT: In a normal day to day life example:
WSDL: When we go to a restaurant we see the Menu Items, those are the WSDL's.
Proxy Classes: Now after seeing the Menu Items we make up our Mind (Process our mind on what to order): So, basically we make Proxy classes based on WSDL Document.
SOAP: Then when we actually order the food based on the Menu's: Meaning we use proxy classes to call upon the service methods which is done using SOAP. :)

Every time someone mentions SOAP/WSDL, I think of objects and classes defined in xml...
"You use SOAP just the same way that you would any PHP class. However, in this case the class does not exist in the local applications file system, but at a remote site accessed over http."
...
"If we think of using a SOAP service as just another PHP class then the WSDL document is a list of all the available class methods and properties. "
http://www.doublehops.com/2009/07/07/quick-tutorial-on-getting-started-with-soap-in-php/comment-page-1/
..and whenever someone talks about REST I think of HTTP's commands (request methods) like POST, GET and DELETE

SOAP -> SOAP(Simple object access protocal) is the application level protocal created for machine to machine interaction. Protocol defines standard rules. All the parties who are using the particular protocol should adhere to the protocol rules. Like TCP, It unwinds at transport layer, The SOAP protocol will be understood by Application layer( any application which supports SOAP - Axis2, .Net).
WSDL -> SOAP message consist of SoapEnevelope->SoapHeader and SoapBody. It doesn't define what would be message format? what are all the transports(HTTP,JMS) it supports? without this info, It is hard for any client who wants to consume the particular web service to construct the SOAP message. Even if they do, they won't be sure, it'll work all the time. WSDL is the rescue. WSDL (Web Service description Language) defines the operations, message formats and transport details for the SOAP message.
REST -> REST(Representational state transfer) is based on the Transport. Unlike SOAP which targets the actions, REST concerns more on the resources. REST locates the resources by using URL (example -http://{serverAddress}/employees/employeeNumber/12345) and it depends on the transport protocol( with HTTP - GET,POST, PUT, DELETE,...) for the actions to be performed on the resources. The REST service locates the resource based on the URL and perform the action based on the transport action verb. It is more of architectural style and conventions based.

You're not going to "simply" understand something complex.
WSDL is an XML-based language for describing a web service. It describes the messages, operations, and network transport information used by the service. These web services usually use SOAP, but may use other protocols.
A WSDL is readable by a program, and so may be used to generate all, or part of the client code necessary to call the web service. This is what it means to call SOAP-based web services "self-describing".
REST is not related to WSDL at all.

SOAP stands for Simple (sic) Object Access Protocol. It was intended to be a way to do Remote Procedure Calls to remote objects by sending XML over HTTP.
WSDL is Web Service Description Language. A request ending in '.wsdl' to an endpoint will result in an XML message describing request and response that a use can expect. It descibes the contract between service & client.
REST uses HTTP to send messages to services.
SOAP is a spec, REST is a style.

Wikipedia says "The Web Services Description Language is an XML-based language that provides a model for describing Web services". Put another way, WSDL is to a web service, as javadoc is to a java library.
The really sweet thing about WSDL, though, is that software can generate a client and server using WSDL.

Some clear explanations (for SOAP and WSDL) can be found here as well.
Difference between a SOAP message and a WSDL?

REST is light-weight in terms of encoding, much more useful for light weight devices i.e. non strict APIs.
REST is format independent. XML, HTML, JSON all options are available.
REST provides abilities for on 2 point message transfer (not surprising since REST stands for REpresentational State Transfer) where WSDL/SOAP interaction is multiple point message interaction.
REST does not require a new extension for XML messages, where in WSDL/SOAP this is the case.
WSDL/SOAP uses multiple transport protocols, REST relies on only HTTP. Therefore WSDL/SOAP can be used like a RESTful way, however simple requests can be overly complicated/heavy weighted.
A simple analogy: REST is like a motoboy delivers your food easy and quick. XML extended WSDL/SOAP more like UPS delivery, more structured and serious stuff but comes with a cost.

A WSDL document describes a webservice. It specifies the location of the service and the methods of the service using these major elements:
data types using in webservice
data elements for each operation
describe the operations that can be performed and the messages envolved
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems to communicate using http and xml.