Here, I will describe some common problems/mistakes faced by Developers while implementing Spring REST with Spring Boot.
Q-1). Whether we can use Body to GET Requests?
A-1). Yes, you can send a body with GET, and no, it is never useful to do so. A payload within a GET Request message has no semantics. Sending a payload body on a GET request might cause some existing implementations to reject the request. The above bold line is clearly stated in the rule RFC7231.
HTTP GET is designed to be idempotent and safe. It means that no matter how many times you call GET on the same resource, the response should always be the same and no change in the application state should occur.
Q-2). Do not use wrong or lengthy names for input parameters.
A-2). Please follow the best practices while defining the name of the input parameters. It should state the purpose of using that resource.
Like -> userId, no need to mention as userId as the GET method will return User as the resource. Better you can use id which is internally resolving as userId.
Also, there is another scenario, that if a situation comes where you need to mention a lengthy name then don’t use underscore (“_”), rather use a hyphen (“-“).
Like ⇾ page_num, don’t use as page_num rather use page-num. But try to avoid such type of naming conventions.
Q-3). Is it good to have a trailing forward slash at the end of URI?
A-3). No, you should avoid appending forward-slash (“/”) at the end of the URI. It is not considered as the best practice.
Like ⇾ https://<<domain-name>>/<<resource-name>>/, the trailing forward slash is not required, the URL should be like this as https://<<domain-name>>/<<resource-name>>
While one can use the forward slash (/) character in the URI to indicate a hierarchical relationship between the resource.
For example – https://explore-animals.com/animals/wild/lion
Q-4). Is it good to have a hyphen (-) in URIs?
A-4). We can use hyphens (-) in URI to improve the readability. But still, keep in mind that while defining URIs with hyphens, don’t exceed the 1024 characters rule of any HTTP methods.
Example – https://bloggers.com/amik-chakraborty/this-is-my-first-blog-post
Q-5). What is the no of characters that any HTTP method can have in URI?
A-5). 1024 characters, this is the no of characters that a URI can have for any HTTP methods you are using. If there is a concept of constructing dynamic URLs, then you should keep in mind that it doesn’t exceed the 1024 characters rule. Otherwise, it will throw an exception.
Q-6). Is it good to have an underscore (_) in URIs?
A-6). No, its better to use hyphen (-) rather than underscore (_).
Q-7). Whether we can use UPPER-CASE Letters in URI?
A-7). As a best practice, use lower-case letters in URI rather than using UPPER-CASE letters. There is a rule named RFC-3986. It says that to maintain the grammar of URI, use lower-case letters. Also, it will create confusion for the user to use.
Example – https://springcavaj.com ⇾ All are in lower-case letters
But if we use any uppercase in the URL as http://SpringCavaj.com ⇾ Then it will create confusion for the User
Q-8). Can we include the file extensions in URIs?
A-8). No, as a best practice don’t use the file extension in URIs. File Extensions should not be used to indicate format preference.
Example – https://explore-animals.com/animals/wild/lion.json -> This is not the best practice to include the format of the file specified. It should be handled by the Media Type
While the URL should be like this ⇾ https://api.example.com/animals/wild/lion
Q-9). Whether we can use Singular or Plural for Endpoint names?
A-9). The best practice is to keep-it-simple. In other words, I can say that to keep the URI format consistent always use plural.
Example – https://online-course.com/users/123/courses/java -> it will return you the list of Java courses taken by the user 123.
Q-10). How to handle Error Code and Error Message?
A-10). Just keep in mind, that don’t return the response code 200 (success) when there is something went wrong. It is a best practice to always use the standard HTTP codes, which are recognized by most clients and developers. It makes life easier that the client would know upfront whether to parse the body or not and how to parse it as a data object or an error object.
It is a good practice to keep in mind that whenever you are returning standard HTTP Error Codes (like 400 – Bad Request, 500 – Server Error), return with an appropriate error message.
Q-11). Is it good to ignore Caching?
A-11). One can easily ignore caching by including one property in the header as “Cache-control:no-cache“. But my suggestion is not to ignore the cache. Using the caching mechanism will increase your application’s efficiency, security, scalability, and performance.
We know that GET is an idempotent request. If we call the GET method to find one resource and after some time use the same browser if we again make a request, then in both cases it will call the server and get the response back. But if we implement the caching mechanism then it will request the server and get the response for the first call, and after that, for any subsequent calls, it will return from the cache. Unless and until some modifications happen for that particular resource, or you have explicitly deleted the cache from the browsers.
Q-12). If you return too much data, then it will take a long response time. Is this feasible?
A-12). The best practice is to always return an average volume of data. If you return too much data, it will take a long response time and the client will not use your API.
As a best practice, use Pagination and Sorting techniques to make the response time faster by returning a low volume of data.
For example, https://online-course/students ⇾ Suppose there are 10 million students registered in this portal. Now if you return the whole 10 million records at a time will have a long response time. But if you break the records and display only 100 records per request. Then the advantage will be the response time will be very low and the size of the data will be less.