Let’s
start with REST as I understand it:
·
REST is
the underlying architectural principle of the web. The amazing thing about the
web is the fact that clients (browsers) and servers can interact in complex
ways without the client knowing anything beforehand about the server and the
resources it hosts. So RESTful Web services are a way of providing
interoperability between computer systems on the Internet.
·
REST-compliant
Web services allow requesting systems to access and manipulate textual
representations of Web resources using a uniform and predefined set of
stateless operations. Other forms of Web service exist, which expose
their own arbitrary sets of operations such as WSDL and SOAP
(REST technology is generally preferred to the more
robust Simple Object Access Protocol (SOAP) technology if only because REST leverages less
bandwidth, which makes it more suitable for internet usage. )
An
API for a website is code that allows two software programs to communicate
with each another.
·
The API spells out the proper way for
a developer to write a program that requests services from an operating system
or other application.
·
With cloud use on the rise, APIs are
emerging to expose web services.
·
REST is a logical choice for building
APIs that allow users to connect and to interact with cloud services.
·
RESTful APIs are used by such sites
as Amazon, Google, LinkedIn and Twitter.
·
A RESTful API
breaks down a transaction
to create a series of small modules.
·
Each module addresses a
particular underlying part of the transaction.
·
This modularity
provides developers with a lot of flexibility, (but it can be challenging for
developers to design from scratch.)
Stateless. A stateless server is a server that treats each request as an
independent transaction that is unrelated to any previous request. (nothing
kept in memory which suits the way the web works).
·
The interaction of any
two software programs involves keeping track of the interaction-specific data,
because each subsequent interaction may depend upon the outcome of the
previous interaction. This becomes more important in distributed architectures
where the client and the server do not exist physically on the same
machine.
·
In two-tier architectures, the responsibility of
tracking this interaction-specific data rested upon the rich clients, This was
not an issue because each client used to reside on an individual
computer. However, within n-tier architectures, the state management
responsibility shifts from the client to the application or the web server.
This introduces the need for some middleware state management extensions, so
that the server can handle multiple concurrent client requests.
·
By deferring the actual
activity-specific state data to such extensions e.g. storing session data in a
database in ASP .NET applications. This helps to free up the memory resources,
in favor of increasing server responsiveness and the ability to entertain more
client requests.
·
In a service
composition, a service may need to store activity-specific data in memory while
it is waiting for another service to complete its processing.
Consequently,
in case of service-orientation, an efficient management of service activity
related data becomes more important as service-orientation puts a lot of
emphasis on service reuse.
·
The service needs to
deal with managing state data, which is created as a result of interacting with
a consumer program, in the context of a particular business process,
·
But it also is used
in relation to the interactions with other types of consumer programs
that are part of multiple business processes.
·
As reusability goes up,
so does the overhead of managing state data.
·
The Service
Statelessness principle provides guidelines in favor of making the service
stateless by shifting away the state management overhead from the services to
some other external architectural component. This further helps in the overall
scalability of the service-oriented solution.
Azure Service Fabric simplifies writing and managing both stateless and stateful
Reliable Services. It si part of the Dynamics 365 Operatissn on premise/hybdrd
solution.
Reliable Services is one
of the programming models available on Service Fabric. Reliable Services gives
you a simple, powerful, top-level programming model to help you express what is
important to your application. Reliable Services get to use the rest of the
Service Fabric APIs directly
"Web resources" were first defined on the World Wide Web as
documents or files identified by their URLs.
Today those have a much more generic and abstract definition
encompassing everything or every entity that can be: identified, named,
addressed or handled, in any way whatsoever, on the Web.
·
In a RESTful Web
service, requests made to a resource's URI will elicit a response that may be
in XML, HTML, JSON or some other defined format.
·
The response may
confirm that some alteration has been made to the stored resource, and it may
provide hypertext links to other related resources or collections of resources.
·
Using HTTP, as
is most common, the kind of operations available include those predefined by
the HTTP verbs GET, POST, PUT, DELETE and so on.
·
By making use of
a stateless protocol and standard operations, REST systems aim for fast
performance, reliability, and the ability to grow, by re-using components that
can be managed and updated, without affecting the system as a whole, even while
it is running.
·
The term representational
state transfer was introduced and defined in 2000 by Roy Fielding in his
doctoral dissertation. Fielding used REST to design HTTP 1.1 and Uniform
Resource Identifiers (URI).
·
The term is
intended to evoke an image of how a well-designed Web application behaves:
o
it is a
network of Web resources (a virtual state-machine)
o
where
the user progresses through the application by selecting links, such as /user/tom, and operations such as GET or DELETE (state
transitions),
o
which result in
the next resource (representing the next state of the application) that
is being transferred to the user for their use.
·
The key constraint is
that the server and client must both agree on the media used, which in the case of the web is HTML.
·
An API that adheres to
the principles of REST
does not require the client to know anything about the structure of the API.
·
Rather, the server
needs to provide whatever information the client needs in order to interact
with the service.
·
An HTML form is an example
of this: The server specifies the location of the resource, and the required
fields.
·
The
browser doesn't know in advance where to submit the information, and it doesn't
know in advance what information to submit. Both forms of information are
entirely supplied by the server.
So, how does this apply to HTTP, and
how is it implemented?
·
HTTP is oriented around
verbs and resources.
·
The two verbs in
mainstream usage are GET and POST
·
However, the HTTP
standard also defines several others such as PUT and DELETE.
·
These verbs are applied
to resources, according to the instructions provided by the server.
·
For example, a user
database that is managed by a web service.
·
Our service uses a custom
hypermedia based on JSON, for which we assign the mimetype application/json+userdb
·
(There might also be an
application/xml+userdb
and application/whatever+userdb
- many media types may be supported).
·
The client and the
server are both programmed to understand this format, but they don't know
anything about each other.
·
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.
·
As the REST principles
go, "Everything is a Resource".
Odata
OData
(Open Data Protocol) is an OASIS standard that defines a set of best practices
for building and consuming RESTful APIs.
OData
helps you to focus on business logic, while building RESTful APIs , without
having to worry about the various approaches to define request and response
headers, status codes, HTTP methods, URL conventions, media types, payload
formats, query options, etc.
·
OData also provides
guidance for tracking changes, defining functions/actions for reusable
procedures, and for sending asynchronous/batch requests.
·
OData RESTful APIs are
easy to consume.
·
The OData metadata, is
a machine-readable description of the data model of the APIs, and that enables
the creation of powerful generic client proxies and tools.
As an architecture
that's built on top of the current features of the Web, RESTful APIs can also
support query strings. For that, OData defines a series of system query options
that can help you construct complicated queries for the resources you want.
