OData and REST and APIs for the layman -these terms are increasingly used so at least get the gist of what they mean

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.

(This principle unfortunately introduces another term which is less often used  so you can look it up here its called HATEOAS: Hypermedia As The Engine Of Application State.)

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.

To get started, take a look at Understanding OData in 6 steps. And then the Basic Tutorial, Advanced Tutorial and Postman Tutorial will provide practical samples to learn OData.

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.