Do both SOAP and REST refer back to the WSDL? I'm having trouble distinguishing between SOAP and REST.
No, only SOAP does.
Essentially SOAP is a protocol with the client and server making agreements as to the kinds of data types transmitted and what actions should be taken by the server for a request. This agreement is specified in the WSDL file.
With REST, there is no agreement as the point of REST is to talk to a resource using only GET, POST, PUT, and DELETE. Nothing about the underlying implementation as specified by a WSDL file should be known to a REST client.
Related
If I am calling a Web APi service and that service makes various other calls to other services, do I use POST or GET?
To elaborate further, let's say I call Web Api Service One saying 'Do the thing'. Web Api One's job when requested thus, is to GET data from Service Two and POST data to Service Three. Perhaps Service One will then update Service Two. Service One will then respond to caller with any success/failure.
My question again is should I the caller, use POST or GET to Service One?
It's all about the semantics of the request. From the RFC 7231:
The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result.
Here's a brief description of some HTTP methods defined in the RFC RFC 7231 (click the links to check the full method definition):
GET: Transfer a current representation of the target resource.
HEAD: Same as GET, but only transfer the status line and header section.
POST: Perform resource-specific processing on the request payload.
PUT: Replace all current representations of the target resource with the request payload.
DELETE: Remove all current representations of the target resource
In addition to the methods listed above, the RFC 5789 standardized the PATCH HTTP method for performing partial updates to a resource.
POST is commonly seen as a "catch all" method, once the target resource process the request payload according to the resource's own specific semantics.
HTTP methods can be classified as safe and/or idempotent and it must be taken into account when designing an API with on the top of HTTP.
Typically I would only use a variety of HTTP verbs (GET, POST, PUT, DELETE etc) when using a REST API. Then the endpoints are resources in their own right. For example:
/car
So the verbs make sense (are you getting a car? creating one? updating one? removing one?)
But when I am not using a REST API the HTTP verbs tend to have less meaning and I generally only use HTTP POST. Otherwise you hit logical problems like you're experiencing here.
eg
/rentacar
This API models an RPC that may cause many resources to change in many ways. It is not a REST API and so the HTTP Verbs don't really relate.
But in honesty, for RPC (remote procedure calls), people choose between GET and POST by either:
GET for operations that don’t modify anything and POST for other cases.
GET for operations that don’t need too much parameters and POST for other cases.
GET and POST on a random basis or always use POST.
Purists prefer 1. But sometimes you don't know when modifications are going to occur. So, take your pick!
I am having confusion around http text 'post' in terms of webservice context. We are having a web service which is built on SOAP protocol, now the integration partner wants to eliminate the SOAP portion of the XML message and wants us to post XML message as 'http text post'.
Is this REST HTTP POST? Please clarify.
POST is an HTTP request method, of which there are many (ex. GET, PUT, DELETE, HEAD...). POST is used to submit data to a server for processing, whereas GET (for example) is used to retrieve data for reading. You can read more here. These methods are used for all HTTP communication, whether the target is a SOAP/REST web service or an Apache server hosting a regular website.
SOAP normally operates using POST requests, although it is possible to use GET with SOAP 1.2 as well. GET requests have more restrictive size limitations than POST requests.
I have to create 2 different websites that would use REST api to interact with a single MySQL database.
I know how to create website with forms..etc using PHP.
How would I use REST api for my websites.I searched and found out that there are libraries for android to use REST api but how to do so in case of a website ?
REST is a architectural pattern, it is not (by itself) an API. APIs can implement REST.
Just like any other API out there, you have to get the documentation for the API and then call it from your source.
Depending on what your requirements are, you may be calling it from javascript or from your PHP backend.
REST is an architecture pattern (you can read more about it at wikipedia) which aims to use HTTP verbs like PUT, POST and DELETE to execute commands against endpoints which represent a resource.
To use REST, your backend server will send normal HTTP requests to the API service; so in PHP this means using the various curl libraries to send requests.
Responses are generally in json; but they could be in any other format (or even in binary) - check with the API documentation that you have to consume.
If all you want is interacting with a REST API, then you need a HTTP client, probably cURL (PHP has a cURL lib). After that you have to check whether your API violates the HATEOAS constraint. If not, then it is called hypermedia API. In that case you have to follow hyperlinks provided by the API in the responses. If it violates the constraint, then it is called web API, and you have to build the method, URL, etc... on the client side again, so your client will break easily by any structural changes of the API. Everything else depends on the message format and the semantic annotations the API uses.
If you want to build a REST API, I strongly suggest you to learn more about the topic. First read the Fielding diessertation and check some existing solutions like HAL or Hydra+JSON-LD. Forget the tutorials. Most information available on the web about how to implement a REST API is flawed.
I am working on REST APIs.
can REST API post/put can include request parameters without a request payload?
where I can find the standard REST specifications
There are no "standard REST specifications". REST is defined by Roy Fielding's thesis Architectural Styles and the Design of Network-based Software Architectures. The HTTP verbs POST and PUT are defined in rfc 2616. REST doesn't necessarily mean a HTTP transport - it is an architectural style which is well suited to web based APIs. Part of that style is that the definition of a service is determined entirely by the contents of messages passed, specifically the way they contain references to other parts of the service (i.e. hyperlinks). As such, if it makes sense for your API to create an empty resource an empty PUT request would be a reasonable way to do it.
Can someone confirm or clarify:
WSDL describes a web service's API to the outside world
SOAP represents an actual transmission of a web service request/response
So, if I understand correctly, WSDL-compliant XML is wrapped inside of SOAP and passed over HTTP to the web service interface, unwrapped, validated against the WSDL, processed, and responded to.
Yes? No? Close?
You're close.
The WSDL describes the contract that a Web Service adheres to or, in other words, the format that the service expects to receive and transmit data in.
SOAP (Simple Object Access Protocol) is one protocol by which Web Services communicate. SOAP will wrap the message with additional information. The message with the SOAP body carries must comply with the service's WSDL for the service to properly process the message.