0% found this document useful (0 votes)
6 views

RestApi Development

The document discusses REST API design principles and compares monolith and microservices architectures, highlighting the benefits of microservices in terms of flexibility and scalability. It outlines key aspects of REST, including the use of HTTP methods, resource naming conventions, error handling, versioning, and security measures. Additionally, it addresses challenges associated with microservices and suggests tools for effective management and deployment.

Uploaded by

Lalit Sonawane
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

RestApi Development

The document discusses REST API design principles and compares monolith and microservices architectures, highlighting the benefits of microservices in terms of flexibility and scalability. It outlines key aspects of REST, including the use of HTTP methods, resource naming conventions, error handling, versioning, and security measures. Additionally, it addresses challenges associated with microservices and suggests tools for effective management and deployment.

Uploaded by

Lalit Sonawane
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

*** REST API ***

Monolith architecture: All components in a single unit, one code base,


coordination challenges, and limited flexibility in scaling.
🧩 Microservices architecture: Breaks down the application into small, self-
contained, and independent services based on business functionalities.
🔄 Microservices communication: Achieved through API calls, message brokers
(asynchronous), or service mesh, allowing different programming languages and
technology stacks.
Challenges and tools: Microservices introduce complexities, but tools like
Kubernetes and HashiCorp's solutions help manage and deploy microservices
applications effectively.
📁 Code management: Choose between Monorepo (easier but potential tight coupling)
and Polyrepo (better isolation, more straightforward pipeline configuration) based
on project size and team structure.

*Rest stands for "representational State transfer" it's a set of simple rules for
how data is exchanged over the web.
*Rest API used HTTP methods like get post and delete that is to interact with
resources which could be anything data Media or even algorithms
*In rest each request from the client to the server must include all the
information necessary to
understand and process the request the server does not store any state about the
client session between request

API Design Principles


* Use HTTP methods correctly
Get - retrieve
Post - create a new resource (not idempotent)
Put - Update an existing resource entirely
Patch - Partially update an existing resource
Delete - Delete the resource

* Use Nouns for Resources


Avoid actions in URI's [/getCustomer, /createCustomer]
Use Hierarchy for nested resources

* Use Appropriate HTTP status codes


ResponceEntity class controls the whole response for ex
ResponceEntity.created() is HTTPStatus 201
ResponceEntity.ok is HTTPStatus 200, ResponceEntity.notFound is HTTPStatus
404

* Error Handling

* Validate Requests
@Valid ensure incoming data is valid.

*Versioning
Versioning is used since over the time, API changes and grows.
URI Versioning - add v1/v2 in URI and use different controllers to access
different URI versions.
Header versioning - headers = "Accept-Version" = v1 (Complex)

*Pagination, Filtering and Sorting


Pagination - to provide data in small chunks.
public Page<User> getUsers(
@RequestParam(dv="0") int page, @RequestParam(dv="10") int size){
Pageable p = PageRequest.of(page,size);
return userRepository.findAll(pageable);

*Security
HTTPS
OAuth
JWT
Spring Security

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy