Understanding API Design Patterns: CRUD, RPC, and Beyond
Microsoft Net Framework

API Design Patterns: CRUD, RPC, and Beyond

1. CRUD (Create, Read, Update, Delete)

  • Concept: Mirrors database operations, usually over HTTP with REST.

  • Structure:

    • POST /users → Create

    • GET /users/1 → Read

    • PUT /users/1 → Update

    • DELETE /users/1 → Delete

  • Strengths: Simple, predictable, aligns with resources.

  • Weaknesses: Limited for complex workflows (e.g., “approve loan” doesn’t map neatly to CRUD).


2. RPC (Remote Procedure Call)

  • Concept: Exposes functions or procedures directly.

  • Structure: Method-style endpoints.

    • POST /sendEmail

    • POST /transferFunds

  • Strengths: Straightforward for action-based tasks.

  • Weaknesses: Can become hard to manage with many verbs; less resource-oriented.


3. REST (Representational State Transfer)

  • Concept: Resource-centric, stateless, uses HTTP verbs and URIs.

  • Principles: Resources identified by URL, actions via standard verbs, hypermedia links possible.

  • Strengths: Clear conventions, web-native, cacheable.

  • Weaknesses: Over-fetching or under-fetching of data.


4. GraphQL

  • Concept: Query language for APIs where the client specifies exact data needed.

  • Structure: Single endpoint (/graphql), queries define shape of response.

  • Strengths: No over/under-fetching, good for mobile apps.

  • Weaknesses: More complex server implementation; caching harder.


5. gRPC (Google RPC)

  • Concept: High-performance binary protocol built on HTTP/2 with Protocol Buffers.

  • Structure: Contract-first (proto files), strongly typed methods.

  • Strengths: Fast, efficient, supports streaming.

  • Weaknesses: More complex debugging; not human-readable.


6. Event-Driven APIs (Pub/Sub, Webhooks, WebSockets)

  • Concept: Instead of request/response, the server pushes updates.

  • Examples: Webhooks on payment success, WebSockets for chat.

  • Strengths: Real-time, decoupled.

  • Weaknesses: Harder to guarantee delivery and order.


7. Composite / BFF (Backend for Frontend)

  • Concept: One API tailored per client (mobile, web, IoT). Aggregates multiple services.

  • Strengths: Optimized responses, shields clients from complexity.

  • Weaknesses: More maintenance if many client-specific backends.


Summary Table

Pattern Best for Weakness
CRUD (REST style) Resource-based operations Poor for complex workflows
RPC Action-based tasks Verb explosion, hard scaling
REST General-purpose APIs Over/under-fetching
GraphQL Flexible data fetching Complex, caching issues
gRPC High-performance, microservices Debugging, binary payloads
Event-driven Real-time notifications Delivery/order guarantees
BFF Multi-client applications Extra maintenance overhead

Share This with your friend by choosing any social account


Upcoming Articles
Copyright Future Minutes © 2015- 2025 All Rights Reserved.   Terms of Service  |   Privacy Policy |  Contact US|  Pages|  Whats new?
Update on: Dec 20 2023 05:10 PM