Resource URI એ કોઈ વસ્તુ તરફના noun-આધારિત path જેવો વંચાવો જોઈએ, ક્રિયા જેવો નહીં. HTTP method પહેલેથી જ verb પૂરો પાડે છે, તેથી URI એ ફક્ત resource ને સ્પષ્ટ અને સુસંગત રીતે ઓળખવાની જરૂર છે.
Resource URI એ કોઈ વસ્તુ તરફના noun-આધારિત path જેવો વંચાવો જોઈએ, ક્રિયા જેવો નહીં. HTTP method પહેલેથી જ verb પૂરો પાડે છે, તેથી URI એ ફક્ત resource ને સ્પષ્ટ અને સુસંગત રીતે ઓળખવાની જરૂર છે.
GET /users/42 — GET /getUser?id=42 નહીં. Method (GET) એ verb છે./users એ collection છે; /users/42 એ એક member છે. બધે બહુવચન રાખવાથી તે અનુમાનિત રહે છે./users/42/orders = "user 42 ના orders".kebab-case, lowercase વાપરો. /blog-posts, /blogPosts કે /Blog_Posts નહીં./users?role=admin&sort=-created_at./users users નું collection
/users/42 એક user
/users/42/orders user 42 ના orders (sub-collection)
/users/42/orders/1001 એ user નો ચોક્કસ order
/orders/1001 એ જ order, top level પર પણ સુલભ
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
એક કે બે levels થી વધુ ઊંડું nesting ટાળો — /users/42/orders/1001/items/5/reviews નાજુક બની જાય છે. એકવાર order નો પોતાનો ID હોય, /orders/1001 ને પસંદ કરો. CRUD માં બંધ ન બેસતી ક્રિયાઓ માટે (દા.ત. "email મોકલો"), controller-style sub-resource સ્વીકાર્ય છે: POST /users/42/verify-email.
સુસંગત naming એ છે જે API ને સાહજિક બનાવે છે — જે developer એ /users અને /users/42 જોયું છે તે docs વાંચ્યા વગર /products અને /products/99 નો સાચો અંદાજ લગાવી શકે. Interviewers આનો ઉપયોગ એ માપવા કરે છે કે તમે RPC calls (/doThisThing) ને બદલે resources (REST માનસિકતા) માં વિચારો છો કે નહીં. સૌથી સામાન્ય anti-patterns — path માં verbs, અસંગત બહુવચન, અને ઊંડે nested URLs — બધા API ને શીખવા અને જાળવવા અઘરા બનાવે છે, અને એ એવા developer નો સંકેત આપે છે જેણે REST ની uniform-interface constraint ને આત્મસાત નથી કરી. સારો URI design concerns ને પણ અલગ રાખે છે: path માં identity, query string માં filtering અને pagination, જે caching અને routing ને સ્વચ્છ રાખે છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો