REST Web Services Introduction

Rest technology is used on the project and should be a service concept for rest. The primary is the external (BPM) Exposure API to provide service. Recommend a quality article, then the system will learn a little bit of restful concept. Http://kb.cnblogs.com/page/91827/REST Introduction

If you're talking about rest, it's best to start with the web.

What is the web? The reader can view the Wikipedia entry (HTTP://ZH.WIKIPEDIA.ORG/ZH-CN/WEB), I will not say more specific. In short, the Web is our most popular service on the internet, even in some people's minds, the Internet is the Web. Of course, the Web is only part of the Internet, but most people use it, and all of the sites we visit are Web-based.

So what is the relationship between the web and rest? We'll talk about some of the basic technologies that make up the web, URIs (Uniform Resource identifiers, which identify resources), HTTP (Hypertext Transfer/Transfer Protocol for manipulating resources), hypertext (hypertext, which describes the content and state of a resource, and we can use HTML, XML, JSON or a custom-formatted text to describe any resource).

Then let's look at what is rest? In fact, rest is not an emerging technical language, nor is it a new technical framework. To be precise, rest is just a concept, style, or constraint, and it's a recommendation to return to HTTP itself.

Rest is by Roy Thomas Fieding in his doctoral dissertation "Architectural Styles and the Design of network-based software Architectures" (" Architecture style and web-based software architecture design. Roy Fielding is a co-creator of the Apache Foundation, and is also the main designer for Web-based protocols such as HTTP and URIs. From Roy Fielding's background, I think you should be able to understand the relationship between rest and the web. Indeed, our focus on technology in rest is actually just URIs, HTTP, hypertext.

In his paper, Roy presents a few constraints that a restful application should have.

• Each resource should have a unique identity
• Use standard methods to change the state of a resource
• Self-description of request and response
• Multiple representations of resources
• Non-stateful service

Roy believes that only applications with the constraints above can be considered as rest applications, but many of the so-called rest applications or services are not really rest applications.

I found that, in fact, many so-called rest applications, just RPC, this situation is actually very normal, because RPC is actually more in line with the general Programmer's thinking. In fact, there is still a big difference between rest and RPC, let's say the difference between rest and RPC.

• Rest emphasizes that the resource has a unique URI, whereas RPC emphasizes the process (verb), which is called by a unified interface.
• Rest returns to HTTP's original design; RPC simply uses HTTP as the transport protocol.
• Rest is hypertext-driven, and RPC is method-driven.
• Rest emphasizes the semantic visibility of HTTP communication through message headers and standard HTTP methods, and RPC encapsulates semantics in the HTTP message body.

Rest application Scenarios

Through the above introduction, we should have some basic understanding of rest, due to the RESTF application of these constraints, we can easily understand and use the rest of the service (as long as you understand HTTP).

In fact, we often make a mistake is that when we understand a new technology, we will use this technology to solve all the problems. There is a saying: "In the eyes of the hammer, all things are nails", in fact, rest is only one of the tools in our toolbox, we hope not to consider it as our only tool. So let's talk about scenarios that are appropriate for restful use and scenarios that are not suitable for rest.

In my opinion, the most suitable scenario for rest is the need for external exposure, when we can take advantage of rest's self-description, stateless, unique identity and other features to provide a clear, friendly API, and now the Jesery, The JAX-RS framework, such as Resteasy, also provides support for OAuth, which basically guarantees service security.

The least suitable scenario is a service call between systems that have high performance requirements, and when you use rest at this point, all of the rest's features become a drag. At this point, it would be better to choose the lower communication protocols and methods, such as ice. Such a mistake, I have committed, and later through a long time of efforts to slowly change this error.

Planning REST Services

When we are planning a rest service, the most critical concept is "resources".

What are the resources? Broadly speaking, anything that is useful is a resource. In a narrow sense (in a web environment), it is an entity that can be stored, connected to a computer, and manipulated through bitstream. An entity wants to be a resource, it must have a URI. Here the URI contains a twofold meaning: 1) It is the name of the resource 2) it is the address of the resource.

When we plan the URI, there are a few things we would like to notice:

• A URI identifies a resource, but a resource can be identified by multiple URIs.
• Resources are also hierarchical, and this level should be fully reflected on the URI.
• When planning a URI, you need to define some of the keywords or symbols that are identified within the team that have special meanings and cannot be used casually.
• A URI-defined document is required for later query and maintenance.
• You can use URI template to describe the definition of a URI. How to use URI template also see this article

After we have defined the resources, the next thing to do is to define how the resources are manipulated and the presentation format of the resources.

Using the basic methods provided by HTTP to manipulate resources, the general operation is defined as follows: POST (create Resource), get (Get Resource), PUT (modify Resource), delete (delete). They correspond exactly to crud.

The general choice of resources is XML, but I recommend using JSON to express resources. The amount of transmission in the network is also small, but also easy to parse JavaScript, and now other language parsing is also very convenient things. However, the most critical thing is to use less resources, so that the same resources can serve more people.

The following diagram is a good illustration of the most important triangular relationship around resources in rest.

There is a good article on INFOQ on how to plan the rest service how to get (get) a cup of coffee-Starbucks rest case study, and it is estimated that by reading this article, you should have a deeper understanding of how to plan rest services.

Choose a quick and easy rest framework

There are also many frameworks for rest, and it is recommended that you use Jersey and Resteasy to create your own rest services.

Both frameworks are of a noble character, Jersey is the JAX-RS implementation reference provided by Sun, the most sufficient and fast support for Jax-rs, and basically all the new features of Jax-rs are first embodied in Jersey, and provide a fairly complete example for you to learn. Resteasy is a project by JBoss Open Source, it also has a lot of advantages, and the document is better than Jersey, but with his JBoss application server binding is very close, I personally do not like, if it is familiar with the JBoss application server can choose Resteasy, It makes people feel more mature, unlike jersey will soon add new features. However, you need to choose according to your personal preferences.

How to use jersey to quickly create rest apps, see quickly building rest apps with jersey, how to use Resteasy to quickly create rest apps, see Using Resteasy to quickly create rest apps.

Places to note for publishing rest services

I also mentioned that the best scenario for using rest is to provide public services externally, known as OPENAPI. Once the API is open, it is difficult to control the use and adjustment of these APIs, and if it is poorly thought out before opening these APIs, then later maintenance would be a very troublesome thing. So, when we decide to open the API, then we must pay attention to some things, the following is my experience summary.

When exposing APIs externally, you need to be aware of version planning for future API upgrades and maintenance. API version planning, before opening the API, is a very easy to ignore. But once your API is open, you'll find it's a stupid thing to do without a version plan for an open API. When your API is used by more and more people, when you open APIs more and more, once an API to upgrade, input and output changes, you simply do not know who should be notified to upgrade, solve the problem is also very troublesome.

Similarly, since exposing APIs, it is difficult for you to control the number and intent of the API calls and to control the number and frequency of critical API calls to avoid malicious attacks. However, the number and frequency should be controlled in what degree, depends on your API's critical level and load capacity, each system will have its own judgment, as long as you have mastered this yardstick, should not have a problem.

In addition, due to browser limitations, only HTTP GET and post methods can be used, if you call the rest service through Ajax directly, when you need to use HTTP put or Delete method to invoke the service, It is best to consider using the overloaded Post method to invoke services that require the use of the put and delete method calls through post.

REST Web Services Introduction