I'm reading articles about REST including a tutorial. I've seen this site http://www.vogella.com/tutorials/REST/article.html, and there is a part for explaining the rest as:
In a REST based architecture, you have a REST server which provides access to the resources. A REST client can access and modify the REST resources.
Now I've searched what is the meaning of REST server and REST client but I could not find a good answer. Could someone explain them?
The server exposes the API and the client makes use of it.
For example, Twitter has data it wants to share (Tweets among other things), so it exposes an API which is served by a REST server (several, in all likelihood). You want to write a mobile app that uses that API to fetch and expose tweets to a user, your mobile app would be the REST client.
The easiest way to think of it is this:
When talking about server and client, it's always relative to the code you are discussing at the moment. The code that has the web server answering the requests is always the server portion. The code that is contacting the web server is always the client.
In addition to the @Paul and @Berin answers, which are very correct and concise.
Now I've searched what is the meaning of REST server and REST client but I could not find a good answer. Could someone explain them?
The short answer is
A little bit longer answer is
RESTful server (applications) are applications capable to provide us with resources and management of these resources on the WWW employing the HTTP specifications as communication protocol.
RESTful client (applications) are applications capable to consume and operate with resources exposed by RESTful servers, under the same premises.
In layman's word,
Leonard Richardson and Samy Ruby came up with an architectural style that embraces all these premises and constraints. Resource Oriented Architecture (book). Its interpretation of REST applications (APIs and services) has been broadly adopted by the community and has promoted the proliferation of books, blogs and articles regard this topic. Having in common all of them, the Fielding dissertation.
Out there, in the wild market of the RESTful applications, we will see applications claiming to be RESTful when the truth is that they don't totally accomplish with the Fielding's constraints.1
Accomplishing all the architectural constraints of REST is not exempt of tradeoff. The community has had to adopt a certain degree of flexibility at the moment of implementing these constraints. As usual, it's a matter of suitability and cost-benefit.
Among the constraints, the Uniform interface stands out from the others. This constraint is especially relevant because is the one that makes us employ the HTTP semantics and contents for representing our business (services, models, etc) in a RESTful way.2
Each implementation of REST differs notably from project to project and from provider to provider. It's understandable since each of them has to deal with different requirements, needs and resources. Ultimately, requirements and needs prevail over the rest.
1: Does it means they are not RESTful? Well, that's open to debate and opinions. Both things off-topic here.
2 : An example of its relevance is the large number of articles, guides or questions in SE and SO about how to successfully implement the URIs, Http Methods, Http Status, etc; to meet successfully the expectations of the business.
Now I've searched what is the meaning of REST server and REST client but I could not find a good answer. Could someone explain them?
When in doubt, go to the source: Fielding's dissertation where he defines the REST architectural style.
In Chapter 5, he describes Client-Server as the first of the constraints.
Separation of concerns is the principle behind the client-server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
The description of the Client-Server architectural style is in Chapter 3, which Fielding attributes to Gregory Andrews
A client is a triggering process; a server is a reactive process. Clients make requests that trigger reactions from servers. Thus, a client initiates activity at times of its choosing; it often then delays until its request has been serviced. On the other hand, a server waits for requests to be made and then reacts to them. A server is usually a non-terminating process and often provides service to more than one client.
In short, a REST client and a REST server are both connectors
The essential difference between the two is that a client initiates communication by making a request, whereas a server listens for connections and responds to requests in order to supply access to its services. A component may include both client and server connectors.
Note that Fielding is being somewhat precise in his definition here; he uses the term components to describe the roles that are played.
A user agent uses a client connector to initiate a request and becomes the ultimate recipient of the response. The most common example is a Web browser....
An origin server uses a server connector to govern the namespace for a requested resource. It is the definitive source for representations of its resources and must be the ultimate recipient of any request that intends to modify the value of its resources....
Intermediary components act as both a client and a server....
In common discourse, I think you'll find that most understand REST client to mean the user agent component, and REST server to mean the origin server component.
