I am creating an API project in Azure AD B2C in which I want to create a custom UI. For this requirement, I want to know which is better in both "Rest" API & "Graph" API.
Can anyone suggest to me, which is better to use?
While GraphQL is often mentioned as the replacement for REST, both tackle different problems actually.
REST, to start with, is not a protocol but just a style, which, if applied correctly, just decouples clients from servers. A server following the REST principals will therefore provide the client with any information needed to take further steps. A client initially starts without any a-priori knowledge and learns on the fly through issuing requests and processing responses.
While REST is protocol agnostic, meaning it can be build up ontop of many protocols, HTTP is probably the most prominent one. A common sample for a RESTful client is the Web browser we are all to familiar with. It will start by invoking either a bookmarked URI or invoke one entered in the address bar and progress from there on.
HTTP doesn't specify the representation the request or response has to be sent in but leaves that to clients and servers negotiating them. This helps in decoupling as both client and servers can rely on the common interface (HTTP) and only bind strongly onto the known media types used to exchange data in. A peer not being able to process a document in a certain representation (due to the lack of the respective mime type support) will indicate his other peer via a respective error message. The media type, which is just a human readable documentation of the syntax and the semantics of the data payload, is therefore the most important part in a REST architecture. It teaches a peer how to parse and interpret the received payload and to actually make sense out of it, though plenty of people still confuse REST for a JSON based HTTP API with over-engineered URIs they put to much effort in to give the URI some kind of logical sense when actually neither client nor server will interpret it anyway as they will probably use the link relation name given for the URI.
GraphQL on the other hand is a query language which gives the client the power to request specific fields and elements it wants to retrieve from the server. It is, loosely speaking, some kind of SQL for the Web. It therefore has to have knowlege on the available data beforehand which couples clients somehow to the server. If the server will rename some of the fields, the client might not be able to retrieve that kind of information further, though I'm not a GraphQL expert.
As stated above, REST is often confused for a JSON based HTTP API that allows to perform queries on directly mapped DB entries/entities. Keep in mind that REST doesn't prohibit this, though its focus is on the decoupling of peers not the retrieval aspect of some Web exposed database entries.
In the context of Azure AD and its APIs, the term REST API is used when you access the Microsoft Graph service directly. You write all the http communication code, authentication, JSON parsing etc.
The term Graph API or Graph client is a reference to the Microsoft-developed Graph Client SDK which encapsulates the above.
If there is no SDK for your platform, you need to use the REST API directly. Otherwise, I would recommend to use the SDK.
Related
My understanding of REST is simply that a resource needs some means of self-describing itself. My understanding is that this isn't specifically tied to any one protocol (i.e. HTTP) and that there are theoretically numerous ways of achieving this. This is based on an answer to a SO question here: SOAP vs REST (differences) (and unlike the terrible answer to this question: Are Relay and Graphql RESTful?)
Since a GraphQL API is self-describing via introspection, doesn't that mean that GraphQL is RESTful by default since a client can use introspection to figure out how to query it?
While GraphQL is often mentioned as the replacement for REST, both tackle different problems actually.
REST, to start with, is not a protocol but just a style, which, if applied correctly and fully, just decouples clients from servers. A server following the REST principals will therefore provide the client with any information needed to take further steps. A client initially starts without any a-priori knowledge and learns on the fly through issuing requests and processing responses. HATEOAS describes the interaction model a REST architectue should be build upon. It thereby states that a link should be used to request new information which drives its internal flow. On utilizing similar representation to Web forms (HTML) a server can teach a client on needed inputs. Through the affordance of the respective elements a client knows, without any need for external documentation, what to do. I.e. It might find a couple of options to chose one or multiple options from, enter or update some freetext or push some buttons. In HTML forms usually trigger a POST request and send the entered data as application/x-www-form-urlenceded to the server though the form element itself may define something different.
While REST is protocol agnostic, meaning it can be build up ontop of many protocols, HTTP is probably the most prominent one. A common sample for a RESTful client is the Web browser we are all to familiar with. It will start by invoking either a bookmarked URI or invoke one entered in the address bar and progress from there on.
HTTP doesn't specify the representation the request or response has to be sent in but leaves that to clients and servers negotiating them. This helps in decoupling as both client and servers can rely on the common interface (HTTP) and only bind strongly onto the known media types used to exchange data in. A peer not being able to process a document in a certain representation (due to the lack of the respective mime type support) will indicate his other peer via a respective HTTP status code that it does not understand, and therefore can't serve, the requested media-type format. The media type, which is just a human readable documentation of the syntax and the semantics of the data payload, is therefore the most important part in a REST architecture. Even Fielding claimed:
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
A media type teaches a peer how to parse and interpret the received payload and to actually make sense out of it, though plenty of people still confuse REST for a JSON based HTTP API with over-engineered URIs they put to much effort in to give the URI some kind of logical sense when actually neither client nor server will interpret it anyway as they will probably use the link relation name given for the URI.
GraphQL on the other hand is a basically just a query language which gives the client the power to request specific fields and elements it wants to retrieve from the server. It is, loosely speaking, some kind of SQL for the Web, or as Fielding termed it just a Remote Data Access (RDA). It therefore has to have some knowledge of the available data beforehand which couples clients somehow to the server. If the server will rename some of the fields, the client might not be able to retrieve that kind of information further, though I'm not a GraphQL expert.
As stated above, REST is often confused for a JSON based HTTP API that allows to perform queries on directly mapped DB entries/entities. Keep in mind that REST doesn't prohibit this, though its focus is on the decoupling of peers not the retrieval aspect of some Web exposed database entries. As Jim Webber pointed out in a great talk back in 2011 in REST you don't simply expose database tables, you create a domain application protocol which clients will follow along like in a text-based computer game or in a typical Webshop system on the internet.
Especially the linked introspection documentation of GraphQL reminds me of reflection in Java, which couples to the actual class model available. If something along the datamodel changes, how does the GraphQL interaction behave? Is it able to change and adapt? Is a client built for one API able to work with an other API out of the box? All these are basically requirements for a true RESTful client. It basically has to adept to changes in future as the server is free to evolve anytime. It further shouldn't assume certain endpoints returning certain types but use content type negotiation to request a representation it can work upon.
These should give you enough insights to determine for yourself whether GraphQL can be RESTful or not. In my opinion it isn't, but my insights into GraphQL are rather limited, TBH.
Because graphql publishes Metadata about its types, it's entirely plausible (I think) to build a graphql client that could consume any graphql endpoint ...
SOAP did the exact same thing, though it was still an RPC protocol. A client could look up the ...?wsdl information at run-time and then generate a request according to the schema defined in the WSDL dynamically, though what usually happened was that some pre-generated stub-classes were generated based on the WSDL data that got compiled into a specific client. A client dynamically generating a request still needed a routine that defines what message-type to create and what data the message required as input.
While SOAP could potentially define multiple endpoints within a WSDL, in most cases only one was defined though. This endpoint usually only operates on POST requests even when later on (SOAP 1.2) GET would have been possible also.
According to Fielding's thesis
REST uses a resource identifier to identify the particular resource involved in an interaction between components.
, what would be the resource identifier in GraphQL? GraphQL's documentation states that
... In contrast, GraphQL's conceptual model is an entity graph. As a result, entities in GraphQL are not identified by URLs. Instead, a GraphQL server operates on a single URL/endpoint, usually /graphql, and all GraphQL requests for a given service should be directed at this endpoint.
Similar to SOAP, all the request are targeted towards a single endpoint. This has some impact if you consider caching, which is a further constraint REST implies. How are responses cacheable if the URI is the key used to store the response in the cache?
While all of the aggregation stuff and the flexibility may be nice from a consumer perspective, they are, probably, not in line with the constraints of REST, though Fielding himself claimed that REST is not applicable in all situations and that designers should select a style that fits their needs as not every style is the "silver bullet" to each problem. Even Mike Amundsen stated that GraphQL violates at least 3 constraints imposed by the REST architecture, even though GraphQL seems to have changed the default retrieval method from POST to GET since.
Usually, if you aim for long-living APIs that should be free to evolve in future and that has to deal with lots of clients, especially ones not under your direct control, this is when REST starts to shine. Fielding admits that most developers have problems when thinking long-term. For a single frontend-to-backend system or for a tailor-made client interacting with the own API, REST is not the architecture one should probably follow.
Last but not least, in a later tweet Fielding stated
There is no such thing as a REST endpoint. There are resources. A countably infinite set of resources bound only by restrictions on URL length. A client can POST to a REST service to create a resource that is a GraphQL query, and then GET that resource with all benefits of REST…
which I interpret as, don't focus to much on justifying whether GraphQL is REST or not, but think about how you can integrate its benefits into the overall design.
I hope this question will be accepted by stack overflow and not be tagged "opinion based". At least I try...
I talked with a supplier that have to develop for us a web application and The agreement was to use a RESTful interface to access to services provided by my infrastructure.
The REST interface will be developed by my team and their team will develop the UI Interface. The API is in an advanced state of development and it is used by the main application my company is using, so I have to extend it to accomodate this new webapp.
He sent me a draft document to interface their client applications telling me to develop services like this:
http://1.2.3.4:8080/getGPSPositions
telling me:
1) the web frontend will use POST to ask its requests on the above URL
2) the frontend will send objects serialized using JSON with a format s like this (simplified)
{
serviceID: <number>
fromDate: <date>
toDate: <date>
customSQLWhere: <string>
customSQLOrderBy: <string>
}
and response like this:
{
gps_points:
{
#some data object
}
}
This is no REST to me, but JSON+HTTP+RPC with some embedded SQL code, that can be used by an attacker to do some SQL injection...
I think that the correct resource for the above example (about gpsPositions) is:
http://1.2.3.4:8080/gPSPositions?fromDate=...&toDate=...
using HTTP/GET and not HTTP/POST (using fro CRUD operations GET,DELETE,PUT and POST).
I would like to know the technical implications that this kind of approach can have on my project. the API will be exposed on the Internet and in the future it should be used by more supplier for different kind of applications. I also fear to develop an API with two different styles (RPC and REST) should be difficult to read and understand and this will be a problem in the future.
Thank you for your suggestions.
Actually, neither the OP nor his supplier have a correct understanding of REST, IMO.
REST is an architectural style which basically describes how client and servers should interact with each others in order to decouple the former from the latter. The decoupling is achieved by using a backing protocol (HTTP in your case) as transport layer and utilizing the available operations to exchange data. HTTP, which at its core is actually just a protocol to manage resources on a remote location, therefore defines the semantics of each operation, not REST. The decoupling is furthermore achieved by adhering to the rules outlined by the backing transport protocol and by generating new (or utilizing existing) media types both parties can use. Instead of clients coupling to the server API, both couple to intermediary media types instead. This is why Fielding stressed that REST APIs should spend almost all of their descriptive efforts in defining the media types used for representing resources.
Media types per se are just textual descriptions of the syntax and the semantic to expect on receiving data annotated to be of that kind. It is thus a knowledge base for peers on how to process the data and give the data some useful meaning. Clients and servers should further use content negotiation to agree on a common media type both understand. I.e. a client could send a server a list of media types the client knows of and the server will pick the one that is probably most suitable of for the available data or send an unsupported media type failure back to the client to indicate that none of the requested media types is known by the server.
It is furthermore important that the server provides clients with all of the information the client could need to take further actions. The client shouldn't parse meaning out of provided URIs but use the relation name instead and look up the semantics of the relation name within the exchanged media type, i.e. or rely on common standards like next, prev, first, last and self in a collection. This gives the server the freedom to change URIs (and thus move resources around freely) without breaking clients.
One common error of so called RESTful APIs (and clients using those) is, that data is exchanged as application/json or application/hal+json or the like media type only and clients expect resources to be of a certain type (typed resources), which already couple clients to the API. First, application/json or application/xml is a bad media-type in general as it does not hint the users on what content the document might contain. As the example code contains geo-location data probably application/vnd.geo+json would be more appropriate in that particular case.
As REST's focus is on resources, it is questionable IMO if geo-location data make up for a good resource. I at least consider them more of some kind of property of an entity that I'd express as resource. As the location seems to change over time this might be some kind of vehicle information (car, bus, truck, plane, ship, ...) or the like. The proposed response is in itself not very self-descriptive. The client therefore has to have some build in knowledge that somethin like gps_points in a JSON payload contain GPS data probably as time series for someting.
If the server decicdes to return data in a slightly different representation the client risks to break easily this way. On relying on common media types this risk is almost erased unless both parties adhere to the media types specification.
As your actual post more or less questions if POST requests are feasible instead of GET request on retrieving data:
Accoroding to HTTP the client expresses his intent by using one of the available operations defined within the spec. POST is actually an optional operation that should be used if none of the other operations fits the needs. It is kind of a swiss-army knife that can be misued easily. Using it for other operations is not wrong per se. The spec here states:
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
On retrieving data, GET is the preferable operation in case the request does not modify any state on the server or requires to extensive data in via a body (as plenty of HTTP clients limit the length of URIs that can be invoked).
The actual implication of accepting data retrieval via POST is, that this becomes part of your API and you have to support it further on. If you decide to later on "fix" this issue you risk of breaking clients that used this kind of communicating with your API. Some legacy systems might force you though to use such constructs. We have some RPC like Web services where we have to provide services to a wide variety of clients. Some of these are SOAP clients in an old SAP version that gets misued in order to send data to our services. As there is actually no build-in support for HTTP in that ABAP version (as far as I'm told) we have to accept such retrieval requests per POST as well. As I changed our API once in order to accept only GET data retrieval I broke plenty of legacy clients that way unintentionally (even once that could retrieve via GET actually) as the developers just used the first sample in the documentation, which was still POST at that time. Long story short, I had to roll back the changes and support both kinds of queries from now on.
In the explanation of the differences between web services or (Web) APIs there seems to be agreement that REST results in a less coupled architecture.
For example:
https://datatracker.ietf.org/doc/html/draft-li-sdnrg-design-restapi-02 mentions that REST is suited for lowly coupled systems.
https://www.upwork.com/hiring/development/soap-vs-rest-comparing-two-apis/ states that SOAP is too highly coupled
What are the arguments for considering it less or lightly coupled?
In a systems where clients aren't coupled to a specifiy service API, clients will in general be more failure tolerant and thus robust besides being usable for multiple RESTful APIs in general. They will adapt to changes done on the server side while a tightly coupled client will fail to process further requests.
In REST API must be hypertext-driven Fielding explained some of the constraints a RESTful architecture has and what could happend if an API fails to respect these rules.
As clients use links to interact with some remote server, a client has to have some knowledge on what a link is and what actions it can perform on it. This knowledge is in general defined by HTTP (or any other transport protocol) and URI specifications which are often built into the client by relying on certain frameworks or middleware. As links are a major part in REST and clients have to learn respective endpoints somehow Fielding referred to this in his blog post as:
... allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.
though you see plenty of so-called "REST" services that do not support clients on this by not returning URIs at all or not keeping the semantics in the relation but put them into the URI. I.e. you will often see something like URIs like http://some.server.com/api/v1/users/1234 which may give humans a clue of its purpose though if this "knowledge" is ported to a client, it might brake it easily if the server decides (or is instructed by someone) to change anything in the structure. If the server now moves the resource to i.e. http://some.server.com/api/v1/employees/1234 the client wont be able to retrieve data of the user/employee any longer and thus break.
Instead the server should instruct the client with the needed information. It can add some redirect logic which upon invoking the former URI informs the client that the resource can now be found at the new location. The response from the server itself should name such a URI so a client can refer to a resource endpoint via the name instead of analyzing the URI. In HTML this can be achived like this: Sam Sample. Instead of the client analyzing the URI for semantical structures, which also often leads to typed resources, it simply uses what is given by the server and grasp the sense of the URI via the relational name user in the sample.
As HTTP (or any other transmission protocol used) allows to send almost any data between client and server, media types are used by server and clients in order to agree upon a data representation format both sides are able to understand and know how to process. The media type is therefore some kind of knowledge base of what to do with certain data. It can describe the syntactical structure of a document, the necessary elements to expect and the semantics each field has.
According to Fielding
a REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type
If you, however, take a close look at plenty of questions here at StackOverflow most messages are exchanged in plain JSON which does not convey any semantics about the actual data received nor does it hint the client on possible actions that can be performed on this data. HAL and similar media types at least provide some clue on resources and links a client can use in order to process further actions.
As the media type defines a client or server on how to process certain data, it might contain an indication that a link with a relation name like user references a user resource further data of that users can be retrieved from. If the URI of the resource is changed a RESTful client will still be able to process its task as it can deduct from the media type that the user information for a user can be retrieved via the relation name user. Where this URI is actually pointing at isn't of much relevance as the client will only invoke it to retrieve further data from.
As the question also targeted SOAP it is important to know that the SOAP API is very different to REST by nature. The tight coupling is defined via the WSDL contract which defines the server endpoint as well as the operations available to invoke as well as the parameter needed and response types to expect. If the server is adding or (re)moving certain parameters after a client implemented that contract that client will fail from sending further requests and hence needs to be updated before it can continue to work.
In this very simple scenario of letting the server move arround some resources it hopefully becomes clear that a client's knowledge is kept in media types and its state it is aquiring through interacting with the services rather than having it implemented in the code itself (like in SOAP or any propriatary Web-API client). The client is therefore not coupled to the API itself but to the media types which can be added dynamically.
I want to know the main difference between REST and API. Sometimes I see REST API in programming documents, then is REST or API same as REST API? I would like to know more about relation between REST, API and REST API.
REST is a type of API. Not all APIs are REST, but all REST services are APIs.
API is a very broad term. Generally it's how one piece of code talks to another. In web development API often refers to the way in which we retrieve information from an online service. The API documentation will give you a list of URLs, query parameters and other information on how to make a request from the API, and inform you what sort of response will be given for each query.
REST is a set of rules/standards/guidelines for how to build a web API. Since there are many ways to do so, having an agreed upon system of structuring an API saves time in making decisions when building one, and saves time in understanding how to use one.
Other popular API paradigms include SOAP and GraphQL.
Note that the above attempts to answer the question in regards to how the terms are commonly used in web development. Roman Vottner has offered a different answer below which offers good insights into the original definition of the term REST with more technical precision than I have provided here.
REST mostly just refers to using the HTTP protocol the way it was intended. Use the GET HTTP method on a URL to retrieve information, possibly in different formats based on HTTP Accept headers. Use the POST HTTP method to create new items on the server, PUT to edit existing items, DELETE to delete them. Make the API idempotent, i.e. repeating the same query with the same information should yield the same result. Structure your URLs in a hierarchical manner etc.
REST just is a guiding principle how to use URLs and the HTTP protocol to structure an API. It says nothing about return formats, which may just as well be JSON.
That is opposed to, for example, APIs that send binary or XML messages to a designated port, not using differences in HTTP methods or URLs at all.
There is no comparison in REST and API, REST is an API type.
API, in general, is a set of protocols deployed over an application software to communicate with other software components (Like browser interacting with servers) and provide an interface to services which the application software
offers to several live consumers.
And Rest is a form of principle which an API follows in which the server provides information whatever the client desires to interact with services.
REST basically is a style of web architecture that governs the behavior of clients and servers. While API is a more general set of protocols and is deployed over the software to help it interact with some other software.
REST is only geared towards web applications. And mostly deals with HTTP requests and responses. This makes it practically usable by any programming language and easy to test.
API is an acronym for Application Programming Interface and defines a set of structures (i.e. classes) one has to implement in order to interact with a service the API was exposed for. APIs usually expose operations that can be invoked including any required or supported arguments as well as the expected responses. Classical examples here are Corba IDL, SOAP or RMI in the Java ecosystem but also RPC-like usages of Web systems specified in documentation like Swagger or OpenAPI.
REST (REpresentational State Transfer) on the contrary was specified by Fielding in his doctoral thesis where he analyzed how the whole user interactions occurs on the Web. He realized that on the Web only a transport protocol, a naming scheme for stuff as well as a well defined exchanged format is needed to exchange messages or documents. These three parts therefore define the interface to interact with peers in such a ecosystem. The transport layer is covered by HTTP while the naming scheme is defined by URI/IRI. Contrary to traditional RPC protocols which usually only support one syntax, REST is actually independent from a particular syntax. To upkeep interoperability both client and server though need do negotiate about it, which HTTP itself supports through the Accept request and Content-Type response headers. As long as client and server support HTTP, URI/IRI and a set of negotiated representation formats, defined by backing hypermedia capable media-types, they will be able to interact with each other. In a more narrow sense REST therefore has no API other than HTTP, URI/IRI and the respective media types.
However, things are unfortunately not that easy. Most people unfortunately understand something very different in terms of REST or REST API. While URIs should not convey any semantics itself, after all they are just pointers to a resource, plenty of programmers attribute more importance to URIs than they should. Some clients i.e. will attempt to extract some knowledge off of URIs or consider URIs to return responses that represent a certain type. I.e. it may seem natural to consider an URI such as https://api.acme.org/users/1 to return a representation that describes a particular user of that particualar system. An external documentation may specify that a JSON structure is returned that follows a given template such as
{
"id": 1,
"firstName": "Roman",
"lastName": "Vottner",
"role": "Admin",
...
}
can be expected, however, such a thing is closer to RPC than it is to REST. Neither is the response self-descriptive, as required by REST, nor does it follow a representation format that follows a well defined media type that defines the syntax and each of the elements that may form a message. Clients therefore are usually tailor-made for exactly one particular system (or REST API if you will) and can't be used to interact with different systems out of the box without further manual integration/updates. External documentation such as OpenAPI or Swagger are used to describe the available endpoints, the payload-templates that a server will be able to process as well as the expected responses, depending on the input. These documentation therefore is the truth and thus defines the API a client can look up or even use to autogenerate stub classes to interact with the server-side, similar to SOAP.
I therefore don't agree with the answer given by dave. While for RPC systems or the common understood term of REST API his definition may be suitable, for actual REST architectures his explanation isn't fitting at all and thus, IMO at least, not correct either. REST isn't a collection of rules, standards and/or guidelines. It is a set of few constraints that just ensure that peers in such an architecture avoid coupling, support future evolution and become more robust to change.
API is basically a set of functions and procedures which allow one application to access the feature of other application
REST is a set of rules or guidelines to build a web API.
It is basically an architectural style for networked applications on the web which is limited to client-server based applications.
Read more at: https://www.freelancinggig.com/blog/2018/11/02/what-is-the-difference-between-api-and-rest-api/
I've tried to read about what RESTful webservices from Wikipedia etc but I must admit I don't get it. There is a film in which Denzell Washington says "explain it to me like I'm a 5 year old". Can someone do that for me regarding RESTful services?
Bonus points if you know the name of the film.
When I first started with REST, I too had some difficulty getting the "big picture", despite all the documentation out there. Anyways, here's my brief take on REST:
REST is an architectural style for building web services.
REST is built on top of HTTP. Your web service exposes Resources in the form of URIs. Your service allows clients to act upon your service using the standard HTTP verbs (GET=read the resource, POST=create the resource, PUT=update the resource, DELETE=delete the resource).
REST has gained significant momentum in the past few years due largely to (a) Its simplicity over other styles like SOAP. (b) The ubiquity of HTTP. Because HTTP is a time-tested standard, most languages have build-in or 3rd-party HTTP support. You cannot say the same thing about SOAP.
Because REST is a style and not a strict protocol/specification, there is lots of room for interpretation. Many public services that call themselves "REST" do not follow the style to the letter.
RESTful services are services that transfer state represntationally, hence the name REpresentational State Transfer. What this actually means is that data is passed in a declarative manner, which is to say, you get what you ask for.
REST is different from SOAP in that it's not a protocol, and there's no formal specification. SOAP was created to simplify data transfer between applications by using a common interface to access functionality remotely. Unfortunately, to work generally, SOAP is quite complicated, and making SOAP requests is not very straight-forward, requiring XML parsing and generation.
Instead, REST relies on Hyper Text Transfer Protocol (HTTP) to do the heavy lifting. Webservers and server scripts are already built around working within HTTP. To make a request using REST is as simple as a URL request, such as visiting a webpage. The API for a RESTful service can reuse any of HTTP's methods and status codes to signal any errors. Instead of accessing data that's stored in a database through fancy queries and special code, RESTful services allow access that's more similar to a standard filesystem.
The key part of RESTful services, is the declarativeness. A request to GET /widgets/109340 is likely going to get you the data for the widget with an id of 109340. I say "likely" because there's no guarantee. It's up to the implementor. The point is that you can glance at the REST request and know what you expect to be returned. With SOAP, it's much harder to tell whether you have a syntax error.
If /widgets/109340 doesn't exist, instead of passing back a message body, with some specific value to state that the content exists, the server can return a 404 Not Found code, and the user will know that the particular ID doesn't exist. If 403 is returned, the user will know that the item exists, but that they don't have permissions to access it. These request response codes are already supported by programs that make URL requests, because they're common to all servers. This makes REST requests much more resilient.
REST is also flexible on the output format, /widgets/109340 could return a JSON object, but there's no reason it can't return binary data, HTML, XML, SVG, Video, or any other data format. A CDN could use a REST API to serve up versioned content which may or may not be stored on the filesystem: GET /jQuery/1.0.0, GET /jQuery/1.7.1, and GET /jQuery/latest are all RESTful requests.
I'm going to assume you understand what Simple Object Access Protocol (SOAP) is