The document outlines the principles of RESTful behavior in API design, detailing operations on resources such as retrieval, addition, updating, and deletion. It highlights six key properties that define a truly RESTful API, including client-server separation, statelessness, caching, a uniform interface, a layered system, and optional code on demand. Additionally, it introduces Spring Boot as a framework for API development, emphasizing its design patterns and annotations for efficient implementation.

1. Shubham Aggarwal

2. What is RESTful behaviour?
● An architectural style to expose operations upon a
resource
What is a Resource?
● Anything which can be sold
Not to be inferred as an item which
can be sold but anything which
attracts money

3. Operations on a Resource
● GET: Retrieve a resource
● POST: Add a resource
● PUT: Update a resource as a replacement (more on coming
slide)
● DELETE: Remove a resource

4. More operations
● PATCH: Update a resource, specific fields
● OPTIONS: How the servers allows to communicate with,
example,

5. True rest api design
Six properties which define if an API is truly RESTful (HTTP
Standards):
1. Client Server Model
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code On Demand (Optional)

6. Client Server model
● Complete separation: Allowed to evolve and expand
independently from client
● API versioning so that clients are decoupled while
extending API
● Deprecation support

7. Stateless
● Each call is independent from each other
● No use of sessions
● Each call contains necessary data in itself, such as the
API key, access token, user ID, etc
● Store state only at client-side

8. Cache
● Encourage storage of cacheable data
● Response can stored based on TTL
● Explicitly mention if GET should not be cached in
response (using header “Cache-Control” or “Expires”)
● Cacheable: GET
● Non-cacheable: PUT, DELETE

9. Uniform Interface
● API should have a uniform interface in sense of request
and response
● Allows client to talk to server in a single standard
(HTTP) and language (JSON or GraphQL or XML)

10. Layered System
● Different layers and that shit !

11. Code on demand
● Only optional constraint
● Allows for code or applets to be transmitted via the API
for use within the application
● Struggling for adoption as not possible in multi-language
environments

12. Spring boot
● Framework
● Convention over configuration
● Ease of development, built upon Spring MVC
● Excellent use of Template Design pattern for quick TTM
● Singleton Flyweight pattern to manage beans
● Front Controller pattern to manage requests

13. Code clinic: getting started
$ spring run app.groovy

14. Code clinic: Annotations in spring
● @SpringBootApplication
● @Component
○ @Controller
■ DispatcherServlet finds @RequestMapping on classes which are
annotated using @Controller but not with @Component
■ @Component and @Controller are same with respect to bean creation
and dependency injection but later is a specialized form of
former
○ @Service
○ @Repository
■ catch Platform specific exceptions and rethrow them as one of
Spring’s unified unchecked exception

15. Code clinic:
MongoDB entity
design

16. Code clinic:
Define
connection
properties

17. Code clinic:
define REST APIs

18. Code clinic:
define repository

19. Code clinic:
profiling

20. Code clinic:
executable jar

21. Code clinic: RUN

22. Pranam