What is difference between REST api and REST server

Question

I am a little bit confused about this. Can I call my Java server REST server or should I call it REST api? What is the right terminology of this? When can you call something REST api and when REST server?

Thanks

Answer 1

An API is a part of an application (it is never an entire standalone application), the part that is exposed to taking requests from clients (and optionally, returning responses).

A server is the entire application (it can also refer to the physical computer where it is run, but I won't use that definition here).

In other words, the API (a set of functions) is part of the server (a larger set of functions).

The clients might use your library, or their own custom functions, to make requests to your server (through its API). These functions are not called API, nor are they considered part of your server application.

The REST part is just about if your server uses REST architecture.

Answer 2

In simple terms a REST API is a set of URLs that respond to requests made over HTTP, usually using GET POST PUT DELETE HTTP methods. Lots of REST APIs return JSON in the response.

For example, to get a customer's details a REST API might be a GET request to:

https://customers.com/api/1234

which responds with:

{
  "id": 1234,
  "name": "Joe Bloggs"
}

The REST API part is /api/1234. An example of a framework that can be used to simplify creation of a REST API is spring-boot.

The REST Server part is https://customers.com

i.e. The REST Server is there to provide the infrastructure to allow clients to send GET requests to the REST API and receive the response.

Examples of servers that can be used as REST Servers are Apache HTTPD, Tomcat, IIS etc.

To answer some questions:

I should use REST API instead of server

A REST API cannot be used without a Rest Server. The server is the application that accepts requests to the API and facilitates responses from the API. The REST API client will send a GET request to the REST Server for customer.com/api/1234. The REST Server will work out that 'customer.com/api/1234' is a web application running inside the REST Server and will pass control to that web application.

The answer to the next question follows on from that hand-over:

REST API is divided into three tiers - presentation, business and data

That is entirely up to the developer of the REST API. That is the implementation detail of the REST API. For example, a typical flow might be:

1. REST Server receives GET request for customer.com/api/1234
2. REST Server hands control to REST API which receives the URL path parameter 1234
3. REST API determines request is for a customer (business tier)
4. REST API contacts database to load data of the customer with id 1234 (data tier)
5. REST API returns JSON as shown above (presentation tier)
6. REST Server sends JSON response to the client

So all domain operations are handled by the REST API (finding a customer, converting the data to JSON) and all internet operations are handled by the REST Server (client connections, HTTP requests and responses).

In the spring-boot framework, you can develop your REST API using Java and also bundle it with a built-in REST Server (Tomcat) so you only produce a single JAR file that you place on a computer and run.

So in effect, you have three components. The computer (for example a unix server connected to the internet, or even your pc and use http://localhost/customer/api/1234). A REST Server (Tomcat, that can accept HTTP requests) and a REST API (the code you wrote to implement the tiers).

Answer 3

REST is actually an architectural style and according to Robert C. "Uncle Bob" Martin an architecture is about intent. The intent behind REST is the decoupling of clients from servers to allow the latter ones to evolve freely in future without having to fear breaking clients. In order to achieve decoupling clients and servers have to adhere to a certain set of constraints.

REST can't be reduced therefore to the server side alone. It is the whole interaction characteristic or behavior between client and server that determine whether a distributed system follows a REST architectural design or not. If you will you might tackle it from a SOA perspective and say that a server offers services to clients. Even if you have a service implemented that adheres to all constraint put up by Fielding, the whole interaction between server and clients might not be "RESTful" if clients rely on identifying semantics from URIs or expect certain endpoints to return certain types instead of relying on content-type negotiation or implement other kinds of couplings to a respective server.

Jim Webber pointed out that in a REST architecture you primarily implement a domain application protocol that client will follow along as they get all the information served by the server, either through links or form-like representation similar to HTML forms. This concept is summarized as HATEOAS. HTTP, further, is a transport protocol whose domain is the transfer of documents across the Web. You don't invoke services, you just shovel around documents. Any business rules you conclude from the file transmissions are just a side effect of the actual document management. Thereby invoking a REST service is probably also not the correct term actually.

A REST API in itself is misleading in the REST ecosystem as REST is defined to reuse the common interface provided by its transport layer, HTTP in most cases, but it is not limited to it actually. Here HTTP i.e. is the common interface both clients and servers use and neither server nor clients should implement customization to it that may cause interoperability issues. The ultimate goal in a REST environment is that one client may interact with a plethora of services out of the box while a server may serve plenty of different clients, especially ones not under the developers own control, without the need for external documentation and customization overhead, except for the integration of standard document formats, such as HTML or other hypertext driven media-type formats, and link-relations. The coupling should not be between client and servers but between a peer (server or client) and the negotiated representation format defined by a standardized media-type, though through proper content-type negotiation both server and client agreed on a representation format both support and understand.

There is unfortunately a widespread confusion of what REST really is. If you look here at SO or on the Web in general you might get the impression that REST means exposing arbitrary JSON payloads via over-engineered URLs on some HTTP endpoints. Such systems behave like true RPC APIs, similar to SOAP or CORBA. They ship with their own documentation or type definitions that allow de/serialization of messages, clients will usually break if something changes in the structure and similar stuff, and clients targeting one of these APIs can't usually be reused for other APIs out of the box. These are strong hints for coupling and RPC-like behavior. Such "services" need to document the "API" so other developers can implement clients that are able to interact with those systems. As clients demand such documentation, the documentation becomes the actual truth the server implementation has to follow otherwise clients might stop working. Such a coupling also means that a service can't evolve freely in future as it might break clients due to the tight coupling between API documentation and implementation.

As you hopefully can see by yourself, the term API is a bit risky in general if you talk about the true REST architecture model as proposed by Fielding. If you want to communicate about the thing most developers consider being REST, but is RPC actually, the term API might be more fitting. IMO the term "service" covers the thing exposed by server more properly as it covers both definitions accurately.

Answer 4

An API is an Application Programming Interface, which is a way to provide information for other applications (communication among applications). A server is any machine running some process that will execute some service for you.

In other words, however you call it, the important part is that when talking with programmers about this, they will call it API because it's the part related to the code. If you call it server, others may understand that you're talking about the machine itself, not the application running on it.

(This is my vision as a programmer in a big Enterprise and very often I see IT people misunderstand programmers because of these small concepts)