42 most asked RESTFUL Interview Questions And Answers || Frequently asked questions in an interview

RESTful (representational state transfer) API (application programming interface) DLs (description languages) are formal languages designed to provide a structured description of aRESTful web API that is useful both to a human and for automated machine processing. API Description Languages are sometimes called interface description languages (IDLs). The structured description might be used to generate documentation for humanprogrammers; such documentation may be easier to read than free-form documentation, since all documentation generated by the same tool follows the same formatting conventions. Additionally, the description language is usually precise enough to allow automated generation of various software artifacts, like libraries, to access the API from various programming languages, which takes the burden of manually creating them off the programmers.

Introduction
RESTful Service Description Language (RSDL) is an XML vocabulary for designing and documenting hypermedia-driven RESTful Services. RSDL takes a purist hypermedia-driven approach to REST design, requiring that a service have a single entry point, and focusing the design on resources, links, and media types. By representing the concepts of REST in a formal vocabulary, RSDL helps designers of an interface think more clearly about the design process. In our work at EMC Corporation, we teach and coach RESTful design, evaluate proposed REST interfaces for products and internal services, and produce documentation for these interfaces. We created RSDL to make our work more efficient, and we have begun using it as a teaching tool, a standard format for specifications that allows us to track design changes in source code control, test for design consistency with specification-driven programs, and produce documentation.
The REST community has little consensus on how to document a RESTful service beyond this well-known Roy Fielding quote:
Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
While this gives excellent guidance about things that should not be documented, it tells us that we should focus on documenting a media type without telling us how to do so. Well-designed RESTful services are loosely coupled, allowing a client to use the service with no prior knowledge beyond an initial URI and a set of media types. But this gives little concrete guidance to a person who is specifying a RESTful service, and needs to know precisely what information should be provided to a client, which fundamential concepts should be documented for a media type, how dependencies on multiple media types in a single service should be represented, where to document semantics specific to the application domain, or how to organize all of the information that belongs in a specification.
This paper presents RESTful Service Description Language (RSDL, pronounced "risdle"), an XML vocabulary that provides a structured way to specify a RESTful service. RSDL is still being developed.
What should a RESTful service description describe?
The description for a RESTful service should describe semantics specific to the service that go beyond functionality known to a generic REST client. In RSDL, every RESTful service has a single entry point, which corresponds to a home resource, and all other resources can be discovered from the home resource using links. The structure of a RSDL description enforces these design constraints.
A RSDL description focuses on describing the following items:
Media types, with documentation and an optional link to a schema or description that documents each media type used in a service. This includes the kinds of response bodies sent by the server, and how to find links in them and identify specific kinds of link.
Resources, designating one resource as the service entry point.
Links for each resource and the resources they refer to.
Methods allowed for each resource, and the associated requests and responses.
HTTP headers, including custom headers.
Authentication mechanisms and identity providers, which can be specified for the entire service or at the individual resource level.
URI parameters and URI templates.
HTTP status codes, which are described at the service level (not at the individual request level or the resource level), but can be referenced at the request level if need be.
It is important to clearly understand the relationship between services, resources, links, URIs, methods, representations, and media types. A RESTful service is a collection of resources, which are identified by URIs. To start using a service, a client needs an entry point. A service's published entry point is the URI of the home resource. All other resources should be discoverable from the home resource

[themountainguy]

401 - Unauthorized and 403 is Forbidden, please correct it. Also the purpose of POST and PUT is wrong

[vishalgaikwad]

really it's helpful for, basic understanding purpose.

[smahbuhs]

You should add few more questions like how caching is done and what is REST security, btw thanks for the overview.

[michellesong]

The explanation of POST and PUT is reversed.

[arijit]

Incorrect information. The correct information should be POST: Send data to the server to create a new resource. PUT: Update an existing resource or create a new resource if it doesn't exist.