Simpler.Grants.gov Public Wiki
Grants.govSimpler.Grants.govGitHubDiscourse
  • 👋Welcome
  • GET INVOLVED
    • Why open source?
    • How to contribute code
    • How to file issues
      • Report a bug
      • Request a feature
      • Report a security vulnerability
    • Community guidelines
      • Code of Conduct
      • Reporting and removing content
      • Incident response protocol
    • Community events
      • Fall 2024 Coding Challenge
        • Event Submissions & Winners
      • Spring 2025 Collaborative Coding Challenge
        • Event Submissions & Winners
    • Communication channels
  • Product
    • Roadmap
    • Deliverables
      • 🏁Static site soft launch
      • 🏁Static site public launch
      • 🏁GET Opportunities
      • 🏁Open source onboarding
      • 🏁Co-Design Group planning
    • Decisions
      • ADR Template
      • ADRs
        • Dedicated Forum for Simpler.Grants.gov Community
        • Recording Architecture Decisions
        • Task Runner for the CI / CD Pipeline
        • API Language
        • Use Figma for design prototyping
        • ADR: Chat
        • DB Choices
        • API Framework and Libraries
        • Back-end Code Quality Tools
        • Front-end Language
        • Communications Tooling: Wiki Platform
        • Use Mural for design diagrams and whiteboarding
        • Ticket Tracking
        • Front-end Framework
        • Front-end Code Quality Tools
        • Front-end Testing & Coverage
        • Backend API Type
        • Front-end Testing & Coverage
        • Deployment Strategy
        • Use U.S. Web Design System for components and utility classes
        • FE server rendering
        • Use NPM over Yarn Architectural Decision Records
        • U.S. Web Design System in React
        • Communications Tooling: Video Conferencing
        • Back-end Production Server
        • Communications Tooling: Analytics Platform
        • Commit and Branch Conventions and Release Workflow
        • Cloud Platform to Host the Project
        • Infrastructure as Code Tool
        • Data Replication Strategy & Tool
        • HHS Communications Site
        • Communications Tooling: Email Marketing
        • Communications Tooling: Listserv
        • Use Ethnio for design research
        • Uptime Monitoring
        • Database Migrations
        • 30k ft deliverable reporting strategy
        • Public measurement dashboard architecture
        • Method and technology for "Contact Us" CTA
        • E2E / Integration Testing Framework
        • Logging and Monitoring Platform
        • Dashboard Data Storage
        • Dashboard Data Tool
        • Search Engine
        • Document Storage
        • Document Sharing
        • Internal Wiki ADR
        • Shared Team Calendar Platform
        • Cross-Program Team Health Survey Tool
        • Adding Slack Users to SimplerGrants Slack Workspace
        • Repo organization
        • Internal knowledge management
        • Migrate Existing API Consumers
      • Infra
        • Use markdown architectural decision records
        • CI/CD interface
        • Use custom implementation of GitHub OIDC
        • Manage ECR in prod account module
        • Separate terraform backend configs into separate config files
        • Database module design
        • Provision database users with serverless function
        • Database migration architecture
        • Consolidate infra config from tfvars files into config module
        • Environment use cases
        • Production networking long term state
    • Analytics
      • Open source community metrics
      • API metrics
  • DESIGN & RESEARCH
    • Brand guidelines
      • Logo
      • Colors
      • Grid and composition
      • Typography
      • Iconography
      • Photos and illustrations
    • Content guidelines
      • Voice and tone
    • User research
      • Grants.gov archetypes
  • REFERENCES
    • Glossary
  • How to edit the wiki
Powered by GitBook
On this page
  • Context and Problem Statement
  • Decision Drivers
  • Must Haves
  • Options Considered
  • Decision Outcome
  • Pros and Cons of the Options
  • REST
  • SOAP
  • RPC
  • GraphQL
  • Links

Was this helpful?

Edit on GitHub
  1. Product
  2. Decisions
  3. ADRs

Backend API Type

PreviousFront-end Testing & CoverageNextFront-end Testing & Coverage

Last updated 28 days ago

Was this helpful?

  • Status: Accepted

  • Last Modified: 2023-07-19

  • Related Issue:

  • Deciders: Lucas, Aaron, Billy, Sammy, Daphne, Andy, Sarah

Context and Problem Statement

The project will require a backend API. The goal of this ADR is to evaluate and select the API protocol our endpoints will adhere to.

Decision Drivers

Must Haves

  • Well-Established Paradigm & Ease of Adoption: The API protocol needs to be well-established so that the consumer of the API is familiar with how to structure requests and process responses. The API should be simplistic, consistent, clear and backward compatibile

  • Supports Common Uses Cases: The API needs to support our common use cases (e.g. querying a list of NOFOs that match certain search criteria), so that it "just works" out of the box without having to spend much time learning how to use it

  • Easily Maintained and Scalable: The API needs to be relatively easy to maintain and scale, so that we can prioritize developing important product features over managing basic infrastructure. We need a flexible protocol that can satisfy both current and future needs of the project.

Options Considered

  • REST

  • RPC

  • SOAP

  • GraphQL

Decision Outcome

Chosen protocol: REST, because this option is widely opted, is highly scalable and can meet the demands of a large and active user base, and is flexible.

Pros and Cons of the Options

REST

REST (Representational State Transfer) is an architectural style for designing APIs. It uses HTTP verbs to represent different operations, such as GET to retrieve data, POST to create data, PUT to update data, and DELETE to delete data.

  • Pros

    • Simple and easy to understand

    • Widely adopted

    • Supports multiple data formats (flexible)

    • Highly scalable

  • Cons

    • Can be verbose

    • Not as efficient as some other protocols

    • Not as well-suited for complex data structures

SOAP

SOAP (Simple Object Access Protocol) is a protocol for exchanging information between applications. It uses XML to represent data and SOAP messages.

  • Pros

    • Well-defined and standardized

    • Supports complex data structures

    • Secure

  • Cons

    • Can be complex to implement

    • Not as widely adopted as REST

    • Not as efficient as some other protocols

RPC

RPC (Remote Procedure Call) is a style of programming where a client application calls a procedure on a remote server.

  • Pros

    • Efficient

    • Well-suited for complex data structures

    • Secure

  • Cons

    • Not as widely adopted as REST or SOAP

    • Can be complex to implement

    • Not as flexible as REST

GraphQL

GraphQL is a query language for APIs. It allows clients to request specific data from a server, rather than having to know what data is available.

  • Pros

    • Efficient

    • Flexible

    • Easy to use

  • Cons

    • Not as widely adopted as REST or SOAP

    • Can be complex to implement

    • Not as well-suited for complex data structures

Links

#186
REST vs. SOAP vs. GraphQL vs. RPC
Architectural Styles for APIs: SOAP, REST and RPC
Different Types of APIs – SOAP vs REST vs GraphQL
SOAP vs REST - Difference Between API Technologies