How to RESTFul your services and RESTFul services

How to RESTFul your services and RESTFul services

Original article: http://reynders.co/how-restful-is-your-service/
Published on: February 1, September 2013

Today, neither social media platforms nor Enterprise Solutions nor Web services are available. To be cross-platform, it is very important to "expose" Your APIs. Currently, many APIs claim to be RESTful on the surface, but they are actually improved RPC.

Many services that claim to implement the REST style do not even know what it means. So I will explain what REST is and tell you how to RESTful your services.

REST and RESTful

As defined by Roy Fielding, Representational State Transfer (REST) is a software architecture style of distributed systems. For example, Web depends on a stateless (stateless), client-server, and cache-able communication protocol, such as HTTP.

/This/does/not/mean/restful, {"neither": "does this "}

Having a clear and smooth route and returning JSON data does not mean your service is already RESTful. Only when the REST style is adopted and certain rules are followed are truly RESTful services.

Fielding points out the six constraints required by RESTful, of which at least five should be taken seriously:

1. Client-Server constraints (Client-Server constraint)

Use a unified interface to isolate the client and server. The client does not have to care about the business logic and data storage. Similarly, the server does not have to consider the user interface.

2. Stateless constraint) 

Each request contains all the information required by the server. The server does not store the status information.

3. Cache-able constraint) 

The server response must be able to explicitly or implicitly define itself as a cache-able, allowing the client to reuse the response and reduce frequent calls to the server to improve performance.

4. Layered System constraint)

The client does not need to consider intermediary components, such as load balancing and proxy, to improve system scalability.

5. unified Interface constraints (Uniform Interface constraint) 

The client and server use a uniform HTTP-based URI to locate resources. As mentioned above, each piece Of information contains sufficient information for The server to complete subsequent processing, namely, HATEOAS (Hypermedia As The Engine Of Application State ).

6. Code On Demand constraint) 

Optional constraints. Before the server returns information, the client does not need to know how to process the information. It is usually used to add features to a deployed system.

RESTful Web APIs 

Implementing RESTful Web application interfaces and RESTful Web APIs Based on HTTP includes the following features:

• Basic URI, for example: http://api.mysystem.com
• Supports Internet media types, such as JSON
• Use HTTP verbs: GET, POST, PUT, DELETE to complete the operation.
• Hypertext driven)

RESTful Web APIs must be easy to use and provide complete help documentation.

"If you have to ship an SDK for your RESTful API, it is not a RESTful API" - source 

The ASP. NET development team provides a REST-based Web API development framework, called ASP. NET Web API. Click here for additional reading.

Note

The aforementioned constraints are not a standard, but they are the best guide for building RESTful Web applications.

Currently, there are only a few applications that truly implement the RESTful concept, most of which are RPC based on HTTP protocol improvements. Next time you study a new API, you can see if it is truly RESTful.