Web Service - Representational State Transfer (REST|RESTful) Web services

1 - About

Representational State Transfer (REST) Web services, or “RESTful” Web services describes any simple interface that transmits data over a standardized interface (such as HTTP) without an additional messaging layer, such as SOAP.

There is no client context being stored server side (no Sessions). REST is a stateless.

REST is easier to build and consume than using SOAP-services.

REST provides a set of design rules for creating stateless services that are viewed as resources, or sources of specific information, and can be identified by their unique URIs. A client accesses the resource using the URI, a standardized fixed set of methods, and a representation of the resource is returned. The client is said to transfer state with each new resource representation.

Rest is often the base technology behind micro-services

3 - Concept

3.1 - Object Address

Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol.

  • An HTTP GET to a particular URI fetches an object and returns a server-specified set of fields.
  • An HTTP PUT edits an object;
  • An HTTP DELETE deletes an object; and so on.

Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints.

3.2 - Ad Hoc Endpoints

Many applications have no formalized client-server contract. Product developers access server capabilities through ad hoc endpoints and write custom code to fetch the data they need. (They end up with a custom endpoint per view).

3.3 - HTTP Request Method

REST makes use of the HTTP request methods:

  • GET - Read requests
  • PUT- Modify Request
  • POST- Create Request
  • DELETE - Delete Request

When you see an application making PUT or GET requests over HTTP or HTTPS, that’s REST.

3.4 - Context and security

A RESTful interface does not store any information about a particular user's session.

Every request authentication is basic. See Http - Authorization Header (authentication entries)

3.5 - Version

version can be specified:

  • in the url
  • or as a query string. example: api-version: 2015-06-15

4 - Schema

There is actually two schema file format that may defines your Rest API:

5 - Development

5.1 - Contract first

In a contract first / contract-driven development:

  • the schema file is defined first.
  • boilerplate code (ie POJOs) is generated from it
  • client / documentation (known as console) is generated from it
  • and /or every request can be also be controlled from it

Disadvantage:

  • the schema file must be kept up-to-date.
  • once generated, you can't regenerate the boilerplate code
  • not really flexible

5.2 - Code First

In a code first development:

  • the code is annotated with annotation or comment
  • a schema file can then be generated (Example: from jax-rs swagger-core)
  • client / documentation (known as console) can be generated from:

Documentation generator:

6 - Language

6.1 - Java

6.2 - Php

6.3 - Javascript

7 - Test

7.1 - Mock

Via the setting of a proxy, you can set up what's called a mock-server

7.2 - Container

Test in container. See test-suite with Blog

8 - List of Known Public API

9 - Documentation / Reference


Data Science
Data Analysis
Statistics
Data Science
Linear Algebra Mathematics
Trigonometry

Powered by ComboStrap