Check our list of essential API Design interview questions and answers that will trend on Design patterns & System Architecture interviews in 2021.
You can also find all 46 answers here 👉🏼 https://devinterview.io/design/apiDesign-interview-questions
REST stands for REpresentational State Transfer. REST is web standards based architecture and uses HTTP Protocol for data communication. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. REST was first introduced by Roy Fielding in 2000.
In REST architecture, a REST Server simply provides access to resources and REST client accesses and presents the resources. Here each resource is identified by URIs/ global IDs. REST uses various representations to represent a resource like text, JSON and XML. Now a days JSON is the most popular format being used in web services.
A HTTP Request has five major parts −
- Verb − Indicate HTTP methods such as GET, POST, DELETE, PUT etc.
- URI − Uniform Resource Identifier (URI) to identify the resource on server.
- HTTP Version − Indicate HTTP version, for example HTTP v1.1 .
- Request Header − Contains metadata for the HTTP Request message as key-value pairs. For example, client ( or browser) type, format supported by client, format of message body, cache settings etc.
- Request Body − Message content or Resource representation.
A Service Oriented Architecture (SOA) is basically defined as an architectural pattern consisting of services. Here application components provide services to the other components using communication protocol over the network. This communication involves data exchanging or some coordination activity between services.
Some of the key principles on which SOA is based are mentioned below
- The service contract should be standardized containing all the description of the services.
- There is loose coupling defining the less dependency between the web services and the client.
- It should follow Service Abstraction rule, which says the service should not expose the way functionality has been executed to the client application.
- Services should be reusable in order to work with various application types.
- Services should be stateless having the feature of discoverability.
- Services break big problems into little problems and allow diverse subscribers to use the services.
Some of the advantages of REST web services are:
- Learning curve is easy since it works on HTTP protocol
- Supports multiple technologies for data transfer such as text, xml, json, image etc.
- No contract defined between server and client, so loosely coupled implementation.
- REST is a lightweight protocol
- REST methods can be tested easily over browser.
Some key characteristics of REST includes
- REST is stateless, therefore the SERVER has no state (or session data)
- With a well-applied REST API, the server could be restarted between two calls as every data is passed to the server
- Web service mostly uses POST method to make operations, whereas REST uses GET to access resources
No, you are not supposed to use POST or GET. GET operations should only have view rights
Caching refers to storing server response in client itself so that a client needs not to make server request for same resource again and again. A server response should have information about how a caching is to be done so that a client caches response for a period of time or never caches the server response.
There are two types of web services:
- SOAP Web Services: Runs on SOAP protocol and uses XML technology for sending data.
- Restful Web Services: It’s an architectural style and runs on HTTP/HTTPS protocol almost all the time. REST is a stateless client-server architecture where web services are resources and can be identified by their URIs. Client applications can use HTTP GET/POST methods to invoke Restful web services.
Resources are identified by logical URLs; it is the key element of a RESTful design. Unlike, SOAP web services in REST, you view the product data as a resource and this resource should contain all the required information.
The architectural style for creating web api are
- HTTP for client server communication
- XML/JSON as formatting language
- Simple URI as the address for the services
- Stateless communication
Some of the advantages of web services are:
- Interoperability: Web services are accessible over network and runs on HTTP/SOAP protocol and uses XML/JSON to transport data, hence it can be developed in any programming language. Web service can be written in java programming and client can be PHP and vice versa.
- Reusability: One web service can be used by many client applications at the same time.
- Loose Coupling: Web services client code is totally independent with server code, so we have achieved loose coupling in our application.
- Easy to deploy and integrate, just like web applications.
- Multiple service versions can be running at same time.
SOAP stands for Simple Object Access Protocol. SOAP is an XML based industry standard protocol for designing and developing web services. Since it’s XML based, it’s platform and language independent. So our server can be based on JAVA and client can be on .NET, PHP etc. and vice versa.
- Representational state transfer (REST) is a style of software architecture. As described in a dissertation by Roy Fielding, REST is an "architectural style" that basically exploits the existing technology and protocols of the Web.
- RESTful is typically used to refer to web services implementing such an architecture.
I need to constantly access a server to get real time data of financial instruments. The price is constantly changing so I need to request new prices every 0.5 seconds. Which kind if API would you recommend?
The most efficient operation for what you're describing would be to use a webSocket connection between client and server and have the server send updated price information directly to the client over the webSocket ONLY when the price changes by some meaningful amount or when some minimum amount of time has elapsed and the price has changed.
Here's a comparison of the networking operations involved in sending a price change over an already open webSocket vs. making a REST call.
webSocket
- Server sees that a price has changed and immediately sends a message to each client.
- Client receives the message about new price.
Rest/Ajax
- Client sets up a polling interval
- Upon next polling interval trigger, client creates socket connection to server
- Server receives request to open new socket
- When connection is made with the server, client sends request for new pricing info to server
- Server receives request for new pricing info and sends reply with new data (if any).
- Client receives new pricing data
- Client closes socket
- Server receives socket close
As you can see there's a lot more going on in the Rest/Ajax call from a networking point of view because a new connection has to be established for every new call whereas the webSocket uses an already open call. In addition, in the webSocket cases, the server just sends the client new data when new data is available - the client doens't have to regularly request it.
A webSocket can also be faster and easier on your networking infrastructure simply because fewer network operations are involved to simply send a packet over an already open webSocket connection versus creating a new connection for each REST/Ajax call, sending new data, then closing the connection. How much of a difference/improvement this makes in your particular application would be something you'd have to measure to really know.
PUT puts a file or resource at a particular URI and exactly at that URI. If there is already a file or resource at that URI, PUT changes that file or resource. If there is no resource or file there, PUT makes one
POST sends data to a particular URI and expects the resource at that URI to deal with the request. The web server at this point can decide what to do with the data in the context of specified resource
PUT is idempotent meaning, invoking it any number of times will not have an impact on resources.
However, POST is not idempotent, meaning if you invoke POST multiple times it keeps creating more resources
You can also find more Design patterns & System Architecture interview questions here 👉🏼 https://devinterview.io/design/