Request & Response

• Used when everything is done or asked for is within a single request-response

Model

• Steps

  • Client sends a Request

  • Server parses the Request

  • Server processes the Request

  • Server sends a Response

  • Client parses the Response and consume

• In general parsing and processing a request/response is considered as one step

Parsing

• parsing aka serialization aka marhsalling/unmarshalling

  • turn some data into a format for transfer into something that can be used in code (objects), and vice versa

• The cost of parsing needs to be thought about

  • can be very expensive

    • ie xml

    • size can of payload, if you use better format (ie json) but is massive then it can be expensive

• Trade off between human readable (xml/json) but slow, vs non human readable (protbuff) but fast

• Trade off between schema for consistency and correctness vs schemaless for size and freedom,

Uses

● Web, HTTP, DNS, SSH ● RPC (remote procedure call)

• Leaky abstraction ● SQL and Database Protocols ● APIs (REST/SOAP/GraphQL) ● Implemented in variations

Anatomy

• A request/response structure (the protocol) is defined and agreed by both client and server

• Request/response has a boundary

• Defined by a protocol and message format

  • format needs to be understood if it is to be used (ie json) so it can parse it

Issues

• if sending request, there are so many places that can fail

  • ...

  • To avoid this, esp if sending a large request, can split the request payload into smaller requests with id. IF one/many fails, then the server can say they didnt get them ask to be resent. This requires extra logic on client and server to make the req/resp more reliable

    • same can apply to a response, if part is missing the client can ask the server for missing parts

• Notifications dont work well

  • client needs info from server to find out if somethign is done, or if new info to get

  • end up doing polling, constantly call the server on schedule to check, poor scaling and extra load on server

• chat

  • high latency

  • spam server with empty requests

• Very long running requests

  • waiting a long time

  • Can end up failing, and having to restart it from scratch

  • if disconnects, then the client may not what to do

    • use of time outs

  • Blocking, have to wait for it to finish before continuing

    • Depends if wrapped in callback/future

  • better to use aysnc process