Please enable JavaScript.

Coggle requires JavaScript to display documents.

UDP = FAST: ++ Simplier ++ Faster -- Not reliable -- Not ordered --…

- - - - Base for:
        
        GraphQL:
        
        Protocol, released by Facebook
        
        It's purpose is to improve REST and to solve overfetching and underfetching
        
        It can fully replace REST for reading (GET) & mutations or modifying (POST, PUT, DELETE)
        
        It's based on HTTP
        
        QL (Query Language)
        
        You can specify which fields to return
        
        You can specify nested entities to return
        
        Requests & Responses are in JSON format
        
        PROS:
        -- You can specify what to fetch
        -- Allows fetching entities with single request
        -- Great for reporting systems
        
        CONS:
        -- Results are less cache-able
        -- Not very well supported outside JS ecosystem
        
        Downsides of REST
        
        Overfetching
        REST fetches by default all fields for an entity, even if we need only part of them or even one of them =>
        -- bigger response
        -- longer time to transfer
        -- more CPU
        -- more memory
        
        Underfetching
        When we specify the fields we need when fetching with REST, we have to do it for every related object, if it's of the same type =>
        --waistful
        
        gRPC:
        
        RPC Protocol, developed by Google
        
        Binary Protocol
        
        Uses HHTP2 as transport
        
        Uses Protobuf (protocol buffer) as IDL
        
        PROS & CONS:
        ++ Language agnostic
        ++ Fast & Type-safe
        ++ Great for communication between services
        ++ Binary messages (not JSON) => more efficient
        ++ Definition is written in *.proto- files, client & server code is generated
        -- Not supported in browsers => it means it's not appropriate for web apps
        -- Messages are not human-readable (binary)
        -- Not appropriate for external communications
        
        RPC:
        
        Text-based protocol
        
        Remote Procedure Call
        
        Invoke service as if it's a local service
        
        Function is described in an abstract language (IDL - Interface Description Language)
        
        Lang. generator generates the function in selected language (i.e. Go/ Ruby/ Java)
        
        Ptotobuf:
        
        Binary protocol => Messages are not human-readable (like JSON)
        
        You have to decode them
        
        IDL is stored in *.proto files
        
        Messages are smaller & faster than JSON & XML
        
        How does it work?
        
        "protoc" will take *.proto file and a selected supported language and will produce the client code and the server code in that language
        
        REST(ful)
        (Not a PROTOCOL, just guidelines how to structure an API)
        
        Build on top of HTTP
        
        Standard URL structure
        
        Standard use of HTTP verbs (methods)
        
        Uses HTTP status codes
        
        JSON as body format
        
        Best Practices:
        
        use pairs "resource-name/resource-id" when designing urls
        
        GET shouldn't change/ update data
        
        Use PUT to switch state (creates new records in DB)
        
        Use POST to update the same record (you may have duplicates updates)
        
        Always provide pagination (?limit=50&offset=100)
      - Request:
        
        Methods (Verbs)
        
        URL
        
        Headers (key - value pairs)
        
        Body (Optional)
        
        Methods:
        
        GET - read
        
        DELETE - delete
        
        POST - create (sometimes is used instead of GET (read), because GET has limit of the length) - not idempotent, if you do the same action twice, it will be handled as two separate records/ actions
        
        PUT - update - idempotent, you may do the same action twice)
        
        PATCH - partial update
        
        etc
      - Response:
        
        Status
        
        Headers (key - value pairs)
        
        Body (Optional)
        
        Status Codes:
        
        100-199 - Informational
        
        200-299 - Successful (i.e. 200 - OK, 201 - Created)
        
        300-399 - Redirection
        
        400-499 - Client Error (i.e. 404 - Not found, 401 - Unauthorized, 403 - Forbidden)
        
        500-599 - Server Error