Summary

This document provides a comprehensive overview of HTTP concepts, including request types, status codes, and other related information. It's a useful resource for those learning about web development and networking.

Full Transcript

HTTP Types of requests: ​ Partial get request: get only a part of the information ​ Conditional get request: restrictions whether we want a fresh copy from the server ​ Head request: only return header body (not also body) ​ Options request: allowed methods (get/post/head) ​ Put requ...

HTTP Types of requests: ​ Partial get request: get only a part of the information ​ Conditional get request: restrictions whether we want a fresh copy from the server ​ Head request: only return header body (not also body) ​ Options request: allowed methods (get/post/head) ​ Put request: put documents in the server ​ Delete: delete data from the server Types of polling -​ Short: client sends small frequent requests where server responds immediately -​ Long: client holds connection until server responds with (new) data Status codes 200: ok 201: created 204: no content to send back 401: bad request 402: unauthorized 403: forbidden 404: not found 500: internal server error 1xx (Informational): Server has received the request and is processing it 2xx (Successful): Request was successfully completed 3xx (Redirection): Page has moved or requires further action 4xx (Client Error): Problem with the request from the client's side 5xx (Server Error): Server failed to complete a valid request+ Html: Hyperlinks: links user can immediately activate? Meta tags: describe html file ​ Viewport: vs ​ used to emphasize a particular meaning in a sentence ​ is used to stress a term (e.g technical) vs ​ is used to show strong importance ​ draw attention without indicating importance ​ Self closing Html tags with size ​ Nested list ​ in ​ in type(to specify counting) ​ i: lowercase roman numerals start(where to start list) reversed(reverse a list) alt → screen readers [text] ​ _blank → new tab ​ _parent → parent frame? ​ _self → same frame? ​ _top → ? ​ framename → ? CSS ​ Pseudo elements are like “::after” and for all selected elements inserts content after its regular content ​ rem vs em??? Javascript: ​ Dynamic: moving (not static) ​ Interpretive: not compiling ​ Weakly typed (implicit type conversion if mismatched types etc.) ​ Cross-platform: multiple platforms (mac, windows) Declaring methods ​ Automatically (Directly declaring: x = “”;) → Redeclaring: syntax error ​ Var (not recommended due to scoping behaviour) → can be accessed outside function ​ Const (same along its lifetime) → block scoped ○​ Objects and arrays binding objects are constant but its values/elements can be reassigned ​ If not declared, but immediately given a value and later declared, no error → declaration type if changed ​ Let (susceptible to be reassigned) → Redclaring: no syntax error → black scoped ​ Notes: ○​ Case sensitive ○​ Null can be assigned ○​ Only declaring is followed with “;”??? Comparison operators ​ Double equals does type conversion ​ Triple equals doesn’t parseInt → becomes int parseFloat → becomes float ​ Both could result in NaN (not a number) Ternary operator ​ [condition] ? [value if true] : [value if false] Switch case statements also have default Form responseValidity doesn’t work in JSDOM for minlength and maxlength Rest API’s REST ​ Uniform interface ○​ Resource identification: Unique URI’s ○​ Resource manipulation through representations: exchange data for other to manipulate ○​ Self-descriptive messages: how to process ○​ Hypermedia as the engine of application state: client doesn’t need to know api URI structure as the server can respond with possible actions (URI’s) ​ Statelessness ○​ Server doesn’t know clients state between requests → scalability ​ Client-server architecture ○​ Separation between client/server supports scalability ​ Cacheability ○​ Responses from server can be marked (un)cacheable → improve performance ​ Layered system ○​ Although a difficult layered system, each layer hides system complexity ​ Code-on-demand ○​ Code can be requested from server → reduces pre-implemented features API: application programming interface ​ Facilitate communication between app and other software systems aka server-client connection REST API request format ​ URI ​ Headers: content type, auth info… ​ Data of message REST API response format ​ URI ​ Headers: content type, server info, caching instructions ​ Data returned by server REST API design ​ Identify resources ​ Define URI’s ​ HTTP methods ​ Representations ​ Ensure statelessness ​ HTTP status codes ​ Hypermedia: allow clients to navigate API dynamically ​ Security: implement authentication/authorization/protecting resources ​ Documentation ​ Testing ​ Versioning ​ Deployment REST API authentication ​ HTTP Basic: client includes username+pass in HTTP headers of req ​ Tokenbased: client sends unique token (generated by server( ​ API key: client includes API key in req header ​ OAuth: delegate authorization ​ JWT (Json web tokens): digitally signed and can include info about user REST API endpoints rules: ​ Nouns for resources ​ Plural nouns for collections ​ No verbs in URI ​ Consistent naming conventions ​ Versioning /v1/[api endpoint] ​ URI hierarchy Security considerations ​ Authentication/authorizations ​ HTTPS (SSL/TLS)??? ​ Cross-Origin Resource Sharing (CORS): other domains?? ​ Token expirations & refresh ​ Input validation ​ Output encoding ​ Rate limiting PATCH?? NodeJS and Express NodeJS ​ Executed on chrome’s javascript runtime → speed ​ Asynchronous and event-driven (events from server) ○​ Tasks work independently/parallel (aka non blocking) → speed ​ Highly scalable?? ​ No buffering?? Express ​ Minimal web app framework for nodejs ​ Handling request,views and connecting database ​ Middleware client-server ○​ MIddlewares have access to req and res ○​ Next middleware is often noted as next ○​ Change/end req/res or cal next middleware ​ Dynamically render HTML pages Require fs vs http ​ Filesystem vs HTTP protocol PostgreSQL Pg pool?? Design patterns and introducing frameworks Why should you stick to an existing design pattern? -​ Costs less effort -​ Less chance of mistakes Why do design patterns work? -​ Good solutions to common design patterns -​ Concrete: not conceptual but offer clear steps and structures -​ Have real word scenarios -​ Reusability -​ React aligns with several design patterns to encourage more maintainable, scalable and efficient applications MVC -​ Model: -​ All logic regarding database -​ View -​ Dynamically rendered html -​ Controller -​ Receives server request based on url → get data from model → requests data representation from view → forwards view to client -​ Handles failures → request error presentation from view React Frontend JavaScript framework → created virtual dom in memory and only changes what needs to be changed useState vs useEffect -​ useState can be used to declare variables that must trigger a rerender whenever their state changes -​ Whereas useEffect can be used to write code that has data dependencies and whenever a dependency changes, the code is rerun -​ useEffect (() => { }, [

Use Quizgecko on...
Browser
Browser