🎤 टॉप 81 Interview Questions
ये सबसे common Java interview questions हैं — tap करके answer खोलो।
Representational State Transfer — EK ARCHITECTURAL STYLE, WEB SERVICES banaने ke liye. HAR CHEEZ, EK "RESOURCE" hai, JISKA UNIQUE URI hota hai, aur STANDARD HTTP METHODS SE, IN RESOURCES PAR, OPERATIONS PERFORM hote hain.
NAHI — REST, EK ARCHITECTURAL STYLE (SET of CONSTRAINTS/PRINCIPLES) hai, KOI FORMAL PROTOCOL (jaise SOAP) NAHI.
GET, DATA FETCH karta hai (SAFE, IDEMPOTENT). POST, NAYA RESOURCE CREATE karta hai (NA SAFE, NA IDEMPOTENT). PUT, RESOURCE ko POORI TARAH REPLACE karta hai (IDEMPOTENT). DELETE, RESOURCE REMOVE karta hai (IDEMPOTENT).
SAME REQUEST, MULTIPLE TIMES SEND karne PAR, SERVER ki STATE, EK HI BAAR CALL karne JAISI hi REHTI hai — GET/PUT/DELETE, IDEMPOTENT hain, POST NAHI.
PUT, POORE RESOURCE ko, REPLACE karta hai. PATCH, SIRF, SPECIFIED FIELDS ko, PARTIALLY UPDATE karta hai.
REST APIs ki "MATURITY" ko, 4 LEVELS (0-3) mein CATEGORIZE karta hai — Level 0 (SINGLE endpoint, RPC-style) se, Level 3 (HATEOAS, TRUE REST) tak.
SOAP, EK STRICT, XML-BASED PROTOCOL hai (WSDL, WS-Security). REST, EK RESOURCE-BASED, ARCHITECTURAL STYLE hai — LIGHTWEIGHT, SIMPLE, FLEXIBLE.
REST, MULTIPLE ENDPOINTS, FIXED RESPONSE SHAPE RETURN karta hai. GraphQL, SINGLE ENDPOINT hai, aur CLIENT, EXACTLY DECIDE karta hai, KYA DATA CHAHIYE.
URLs, NOUNS (RESOURCES) REPRESENT karte hain, VERBS (ACTIONS) NAHI — jaise, /users, /getUsers KI JAGAH.
@RestController = @Controller + @ResponseBody — HAR method ka RETURN VALUE, AUTOMATICALLY, JSON mein SERIALIZE hoke, RESPONSE BODY mein DIRECTLY, CHALA jaata hai.
Class-level, EK "BASE PATH" DEFINE karta hai. Method-level MAPPING, ISKE RELATIVE, RESOLVE hota hai.
@PathVariable, URL PATH ka HISSA hai (RESOURCE IDENTITY). @RequestParam, QUERY STRING SE VALUES LETA hai (TYPICALLY, OPTIONAL FILTERING).
HIERARCHICAL URLs SE — jaise, /api/users/{userId}/orders — LEKIN, 2-3 LEVELS se, ZYAADA, DEEP NAHI HONE CHAHIYE.
jackson-dataformat-xml DEPENDENCY, ADD karके — Client ke, Accept HEADER ke BASIS PAR, AUTOMATICALLY, CORRECT FORMAT, RETURN hota hai.
SAARI, BUSINESS LOGIC, SERVICE LAYER mein, HONI CHAHIYE — CONTROLLER, SIRF, REQUEST PARSE karके, SERVICE CALL kare.
jaise, /api/users/{userId}/orders/{orderId} — DONO, @PathVariable SE, METHOD PARAMETERS mein, MAP hote hain.
@GetMapping, EK SHORTHAND hai, SPECIFICALLY, GET METHOD ke liye — @RequestMapping(method = RequestMethod.GET) ke BARABAR.
DTO, API-SPECIFIC OBJECT hai — ENTITY, DIRECTLY EXPOSE karna, RISKY hai (INTERNAL FIELDS, LEAK ho sakte hain, jaise PASSWORD HASH).
STATUS CODE, HEADERS, aur BODY — SAB, EXPLICITLY, SET kiye ja sakte hain, PROPER, REST SEMANTICS ke liye.
201 (Created), NAYA RESOURCE CREATE hone PAR (POST). 200 (OK), GENERIC SUCCESS ke liye (GET, PUT).
SUCCESS hai, LEKIN, RETURN karne ke liye, KUCH NAHI hai — jaise, DELETE OPERATION ke BAAD.
401 (Unauthorized) = "TUM KAUN HO, PATA NAHI CHALA" (AUTHENTICATION FAIL). 403 (Forbidden) = "PATA HAI, LEKIN, PERMISSION NAHI" (AUTHORIZATION FAIL).
Client, Accept HEADER SE, APNI, PREFERRED FORMAT BATATA hai — Server, AUTOMATICALLY, MATCHING HttpMessageConverter CHOOSE karta hai.
produces, RESPONSE FORMAT CONTROL karta hai. consumes, REQUEST BODY ka EXPECTED FORMAT SPECIFY karta hai.
Jab, EK REQUEST, CURRENT STATE ke SAATH, CONFLICT karta hai — jaise, DUPLICATE ENTRY CREATE karne ki KOSHISH.
SECURITY, aur, FLEXIBILITY, ke liye — jaise, UserCreateDto mein, password hai, LEKIN, UserResponseDto mein, NAHI.
Controller mein, VALIDATION ko, ENFORCE karta hai — INVALID DATA PAR, AUTOMATICALLY, 400 Bad Request, RETURN hota hai.
@NotBlank, STRING, NULL/EMPTY, NAHI HONI CHAHIYE. @NotNull, NULL NAHI HONA CHAHIYE, LEKIN, EMPTY STRING, OK hai.
@Constraint annotation SE, EK NAYA annotation DEFINE karके, aur, ConstraintValidator interface, IMPLEMENT karके.
EK CENTRALIZED CLASS, JO, SAARE @RestController classes ke liye, GLOBAL EXCEPTION HANDLING, PROVIDE karti hai.
Jab, @Valid VALIDATION, FAIL hoती hai — DEFAULT mein, ISE, 400 Bad Request mein, CONVERT kiya jaata hai.
EK INDUSTRY-STANDARD, ERROR RESPONSE FORMAT — type, title, status, detail, instance — CONSISTENT, ERROR STRUCTURE, DEFINE karta hai.
Spring Boot 3.x mein, RFC 7807 ka, NATIVE SUPPORT — STANDARD, ERROR FORMAT, GENERATE karne ke liye.
SPECIFIC EXCEPTIONS ko, PEHLE, HANDLE hone DENE ke liye — GENERIC HANDLER, SIRF, "SAFETY NET" ke roop mein hai.
SAME DTO ke liye, DIFFERENT SCENARIOS (jaise, CREATE vs UPDATE) mein, DIFFERENT VALIDATION RULES, APPLY karne DETE hain.
URI versioning — /api/v1/products, /api/v2/products — SIMPLE, aur, EASY-TO-TEST/DEBUG.
Header versioning mein, Accept HEADER mein, VERSION, EMBED hoती hai — URI, CLEAN RAHTA hai, LEKIN, TESTING, HARDER hai.
Controller annotations ko, SCAN karके, AUTOMATICALLY, EK, INTERACTIVE, API DOCUMENTATION, GENERATE kar DETI hai.
/swagger-ui.html PAR — HAR ENDPOINT ko, DIRECTLY, BROWSER SE, "TRY IT OUT" kiya ja sakta hai.
CONTRACT (OpenAPI SPEC), CODE LIKHNE SE, PEHLE, DESIGN kiya jaata hai — TEAMS, PARALLEL mein, KAAM SHURU kar sakti hain.
NAYE, OPTIONAL FIELDS ADD karna, NAYE ENDPOINTS ADD karna — EXISTING CLIENTS, BREAK NAHI hote.
EXISTING FIELDS, RENAME/REMOVE karna, REQUIRED FIELDS ADD karna — IN ke liye, NAYI API VERSION, CREATE karni CHAHIYE.
Deprecation aur Sunset, HTTP HEADERS SE — CLIENT ko, BATAYA jaata hai, ki, VERSION, KAB REMOVE HOGA.
API CONSUMERS, APNI EXPECTATIONS, EXPLICITLY, DEFINE karte hain, aur, PROVIDER, INKE AGAINST, TEST hota hai.
page, size, sort PARAMETERS ko, AUTOMATICALLY, HANDLE karta hai — REPOSITORY, findAll(Pageable) SE, DIRECTLY, PAGINATED RESULTS, RETURN karti hai.
DATA aur METADATA, DONO — totalElements, totalPages, hasNext(), hasPrevious().
RUNTIME PAR, MULTIPLE, OPTIONAL FILTERS, DYNAMICALLY, COMBINE karne ki, ZAROORAT — SIMPLE, QUERY METHODS SE, YE, POSSIBLE NAHI hai.
Multiple sort PARAMETERS SE — jaise, ?sort=category,asc&sort=price,desc.
SAB FIELDS PAR, SORT ALLOW karna, RISKY hai — SENSITIVE FIELDS (jaise, password) PAR, SORT, INFORMATION LEAK ka RISK, ho sakta hai.
self, first, next, prev, last — CLIENT ko, MANUALLY, page NUMBERS, CALCULATE karne ki, ZAROORAT NAHI.
REPOSITORY mein, findAll(Specification), METHOD, AVAILABLE karvaने ke liye.
Slice, TOTAL COUNT QUERY, SKIP karta hai (FASTER) — SIRF, hasNext() BATATA hai, totalElements NAHI.
DEFAULT, page SIZE aur SORT ORDER, SPECIFY karta hai, AGAR, CLIENT, PARAMETERS, PROVIDE NA KARE.
JSON Web Token — STATELESS, AUTHENTICATION, ENABLE karta hai — HAR REQUEST, APNE SAATH, USER ID/ROLES, CARRY karti hai.
API Keys, TYPICALLY, THIRD-PARTY/SERVICE-TO-SERVICE COMMUNICATION ke liye hain, JWT, INDIVIDUAL, USERS ke liye.
SERVER ko, ABUSE/OVERLOAD SE, BACHANE ke liye — EK CLIENT ko, EK TIME WINDOW mein, LIMITED REQUESTS, KARNE DI JAATI hain.
RATE LIMIT, EXCEED hone PAR — SPECIFICALLY, ISI SITUATION ke liye, DEFINE kiya gaya, STATUS CODE.
EK BROWSER SECURITY MECHANISM — EK WEBSITE ke, JAVASCRIPT SE, EK DIFFERENT ORIGIN ki API, DIRECTLY, CALL NAHI ki ja sakti, JAB TAK, SERVER, PERMISSION NA DE.
YE COMBINATION, BROWSERS mein, REJECT ho jaata hai (SECURITY RISK) — SPECIFICALLY, TRUSTED ORIGINS, LIST karna CHAHIYE.
INCOMING TOKENS (JWT) ko, VALIDATE karta hai — TOKEN, ISSUE NAHI karta (Authorization Server, ISSUE karta hai).
Authorization Server SE, PUBLIC KEYS, AUTOMATICALLY, FETCH ho jaati hain, TOKEN VALIDATION ke liye.
METHOD-LEVEL security — EK SPECIFIC METHOD PAR, DIRECT, SECURITY RULES, APPLY karta hai (jaise, hasRole('ADMIN')).
Spring MVC controllers ko, TEST karta hai, BINA, ACTUAL, HTTP SERVER START kiye — REQUESTS, SIMULATED HOTI hain.
SIRF, WEB LAYER — SERVICE/REPOSITORY layer, @MockBean SE, MOCK karne PADТE hain.
RESPONSE JSON ke, SPECIFIC FIELDS ko, ASSERT karne ke liye, USE hota hai.
EK FLUENT, TESTING API, JO, REACTIVE aur TRADITIONAL, DONO, APPLICATIONS ke SAATH, KAAM karta hai.
BDD-style (given/when/then), API TESTING — EXTERNAL, DEPLOYED APIs ke AGAINST, BLACK-BOX TESTS ke liye, IDEAL.
Microservices ke BEECH, "INTEGRATION CONFIDENCE" DETI hai, BINA, SLOW, FULL-SYSTEM, INTEGRATION TESTS ki, NEED ke.
EK FAKE, AUTHENTICATED USER, SIMULATE karta hai — SECURITY-PROTECTED ENDPOINTS, TEST karne ke liye, REAL LOGIN ki, ZAROORAT NAHI.
ZYAADA, UNIT TESTS (FAST, ISOLATED), aur, KAM, INTEGRATION TESTS (SLOW, REAL, DEPENDENCIES).
Hypermedia As The Engine Of Application State — RESPONSE mein, "AGE, KYA POSSIBLE hai" ke, LINKS, INCLUDED HOTE hain.
Hypertext Application Language — _links KEY ke ANDAR, RELATED RESOURCES ke, LINKS, STRUCTURED WAY mein, DIYE JAATE hain.
Duplicate POST requests (jaise, NETWORK FAILURE ke BAAD, RETRY) SE, HONE WALE, DUPLICATE OPERATIONS ko, AVOID karti hai.
Resource ke, CURRENT STATE ka, EK UNIQUE IDENTIFIER — CONDITIONAL REQUESTS/CACHING ke liye, USE hota hai.
Client, STORED ETag, BHEJTA hai — AGAR, RESOURCE, CHANGE NAHI HUA, SERVER, 304 Not Modified, RETURN karta hai (BANDWIDTH BACHTA hai).
Controller method, IMMEDIATELY, RETURN ho jaata hai — REQUEST-HANDLING THREAD, FREE ho jaata hai, LONG-RUNNING OPERATIONS ke liye.
Agar, EK SERVICE, BAAR-BAAR, FAIL ho RAHI hai, FURTHER CALLS ko, TEMPORARILY, BLOCK kar deta hai (FAIL FAST), CASCADE FAILURE, AVOID karne ke liye.
WebClient, MODERN, NON-BLOCKING, REACTIVE hai. RestTemplate, PURANA, BLOCKING API hai (Spring mein, MAINTENANCE MODE mein hai).
TIGHT COUPLING — AGAR, EK SERVICE, DOWN hai, CALLING SERVICE, bhi, AFFECTED hoती hai.
THROUGHPUT — EK LIMITED THREAD POOL, ZYAADA CONCURRENT REQUESTS, HANDLE kar sakta hai, LATENCY, KAM NAHI, HOTI.
GET/PUT/DELETE, BAAR-BAAR, CALL karne SE, SERVER STATE, SAME, RAHТI hai. POST, HAR CALL PAR, EK NAYA RESOURCE, BANA SAKTA hai.