Request Response
Responses
An API specification needs to specify the responses for all API operations. Each operation must have at least one response defined, usually a successful response. A response is defined by its HTTP status code and the data returned in the response body and/or headers.
An API can respond with various media types. JSON is the most common format for data exchange, but not the only one possible. It contains
- HTTP Status Codes -Under responses, each response definition starts with a status code, such as 200 or 404. An operation typically returns one successful status code and one or more error statuses.
- Response Body - The schema keyword is used to describe the response body. Here response body defines Success Status, Message, Error(if any) and Data.
Request Body
The POST, PUT and PATCH requests can have the request body (payload), such as JSON or XML data. In Swagger terms, the request body is called a body parameter. Many APIs transmit data as an object, such as JSON. Schema for an object should specify type: object and properties for that object. For example, the Event/POST operation with this JSON body:
Here we take SampleEntityDTO object as a request and it will return sampleEntityRepository as a response.
Entities may be part of a business domain. Thus, they can implement behavior and be applied to different use cases within the domain.
DTOs are used only to transfer data from one process or context to another. As such, they are without behavior - except for very basic and usually standardised storage and retrieval functions.
Using DTOs on RESTful APIs written in Spring Boot application is that they can help hiding implementation details of domain objects (ie. entities). Exposing entities through endpoints can become a security issue if we do not carefully handle what properties can be changed through what operations. DTO helps you to keep the integrity of data on spring application.
To avoid having to write boilerplate code to map DTOs into entities and vice-versa, we are using a library called ModelMapper. The goal of ModelMapper is to make object mapping easy by automatically determining how one object model maps to another. This library is quite powerful and accepts a whole bunch of configurations to streamline the mapping process, but it also favors convention over configuration by providing a default behavior that fits most cases.