W3C SVG

Notes

Stock Market

How to design RESTful APIs

Date: 04/11/2020 Frank Gao

This is course note for the following online course: “Designing RESTful APIs” on LinkedIn by Keith Casey

https://www.linkedin.com/learning/designing-restful-apis/welcome?u=3322

Course completed on Apr 11, 2020

Why good API design important?

  • What function to expose
  • How to expose
  • Best way to expose
  • Assumptions
  • Test and validate assumptions
  • Rethink with unexpected use cases
  • Versioning
  • Backward compability

Think of 3 aspects, they have to aligned:

  • What API does
  • What the API makes easy
  • What the user want to do

How to we add an API?

Bolt-on Strategy Facade Strategy Greenfield Strategy
Pro Brute-force approach replacing system piece by piece / keep working system functioning API first o rmobile first mindset. New technologies and architectures
Con Leaking internal design Multiple mindsets / hard to replicate behavior 1:1 Massive upfront investment before benefit from it

How to modeling API?

3 rules

  • Don’t focus on tools
  • Have a consistent process
    • Doc things same way
    • Team work sync always
  • It does not count if not doc it.
    • Design may not clear
    • Risk is unassessed

Conclusion: doc everything

Modeling process

Understand the business process

1. Identify users

  • Who: person/bot/entity
  • Scope: Internal or External?
  • Attitude: Active or Passive?

2. Identify activities

Example: Order an food

  1. place an order
  2. wait for the order
  3. receive the order

3. Break into atomic functions

Above is from user perspective, complete picture is:

  1. customer search for a food and decide
  2. customer place an order with the cashier
  3. cashier passes the order to chief
  4. chief ACK and tell cashier it’s ok to cook
  5. cashier calculate the bill
  6. user make payment, accepted/rejected
  7. if accepted, chief cook the food
  8. deliver the food to customer

Example 2： online book order

  1. view items
  2. add item to cart
  3. remove items
  4. checkout
  5. fullfil and ship order
  6. view order

Validate the API to avoid ambiguities

  • Check the assumptions
  • Ask customer

4. Create API definitions

  • Identify the resources. Find the nouns
    • items/cart/order/customer/bill
  • GET/DELETE/PUT/POST/PATCH
    • GET: retrive a resource
      • List: get items
      • View: get item
    • DELETE: delete a resource
    • PUT: update existing record
    • POST: create/update/anything not fit the first 3 verbs

Now we can decide the definitions of the steps in example 2:

  1. View items
    • GET: List items
    • GET: View item
  2. Add item to cart
    • POST: Create new cart
  3. Remove items
    • PUT: update existing cart
  4. Checkout
    • POST: other resources
  5. Fullfil and ship order
    • Create order is done in POST checkout
    • GET: View order
    • POST: cancel order
  6. Customer Resource
    • Customer registration: POST
    • View customer: GET

Types of relationships between resources

  • Independent
    • Can exist on its own without any other resources
    • Movie and actors
  • Dependent
    • Can only exist if other resource already exists
    • Characters in movies
  • Associative
    • Can be dependent or independent but needs additional information to describe it
    • One actor play multiple characters
    • One character played by multiple actors

5. Validate API

  1. card of scenarios
  2. use microframework

HTTP

  • HTTP is a protocol
  • XML is a markup language
  • JSON is a notation
  • XML standards can add structure
  • JSON spec can add context
  • REST is none of the above

HTTP Response Codes and Headers

REST APIS: 6 constraints

  1. Client-Server Architecture
  2. Stateless Architecture
  3. Cacheable
  4. Layered Systems
  5. Code on Demand
  6. Iniform Interfaces
    • ID of resources
    • Manipulate resources
    • Self-descriptive messages
    • Can discover links

API Design patterns

  • Authentication (AuthN)

  • Authorization (AuthZ)

  • AuthN is who you are

  • AuthZ is what you can do

3 ways to implement them

  1. API Keys: Put in header, url or body
    • Pro:
      • Easiest way
    • Con:
      • leak
      • not easy to update
  2. Implement your own AuthN/AuthZ protocal
    • Pro
      • Only you know
    • Con
      • Untested, unproven
      • Training cost
      • No supporting tool
  3. OAuth 2.0
    • Pro
      • Reliable and well established
      • Massive ecosystem
      • Open-source and commercial options
    • Con
      • Complicated
      • Learning curve steap

API Versioning

2 ways to versioning:

  1. via URL
  2. via Accept Header

Payload

  • Key/Value pairs
  • Media Types
    • Collection + JSON
    • HAL (Hypertext Application Language) + JSON
    • Ion Hypermedia Type

Hypermedia

Hyper: the media is not linear, it can begining in the middle

Advanced HTTP headers: Content negotiation and caching

  • Content negotiation: explicitly response based on the request
  • Caching: ETag
    • Client makes request
    • Server response with ETag
    • Client makes a HEAD rquest (same request as before)
    • If data not changed, server returns the same ETag
    • If data is changed, server returns the full request

Documentations

  • Easy to search
  • Easy to diff
  • Easy to update
  • Readability

Jekyll/Slate

SDK

  • Succinct: user can write less code for same thing
  • Purposeful: doc the behaviors
  • Open Source
  • Idiomatic: puthon SDK should looks like python
  • Logical

Make users’ lives easier

Ask existing user’s demand

Final

Conference:

Book

  • A pratical approach to API Design

如何理解期权中的call和put

Date: 01/27/2021 Frank Gao

Call Put
Long 出钱 - 某个时间前你可以以某个价格买某个股票 出钱 - 某个时间前别人可以以某个价格买你的股票
Short 拿钱 - 某个时间前你可以以某个价格卖某个股票 拿钱 - 某个时间前你可以以某个价格买别人的股票

案例分析：假设现在某股票现价100

Long Call

  • 如果我买1张在30天后的call。交割时价格C 买了S的call，价格P。盈利 (C - S - P)*100
    • 如果我买90元的call，价格肯定超过10元，假设12元。我付出的成本是1200。到了30天，我以90元买了100股。我的总支出是1200 + 90 * 100 = 10200。可以想象我就是在未来用102买了100股。
      • 假如股价102，那我就不亏不赚
        • 假如股票101，那我就亏 101 * 100 - 10200 = -100
        • 假如股价103，那我就赚 103*100 - 10200 = 100
      • 如果我买110元的call，价格会很便宜，比如1元。那我付出的成本就是100。到了30天，我以110元的价格买了100股。我的总支出是110 * 100 + 100 = 11100。可以想象我就是在未来用111买了100股
        • 假如股价111，那我不亏不赚
        • 假如股价110，那我亏 110*100 - 11100 = -100
        • 假如股价112，那我赚 112*100 - 11100 = 100

Long Put

  • 如果我买1张30天后的put。交割价格C 买了S价格的put，价格P。盈利 (S - C - P)*100
    • 如果我买90元的put，价格8元。到了30天后，我必须买到100股然后以90元卖给别人。我能拿到的钱是90 * 100 = 9000
      • 假如股价82，那我就收支平衡。支出是8*100 + 82 * 100 = 9000，收入是9000
      • 假如股价81，那我就赚了。盈利9000 - 800 - 81*100 = 100。所以我的最大盈利是8200，真是个烂策略
      • 假如股价83，那我就亏了。亏了83*100 + 800 - 9000 = 100
    • 如果我买110元的put，价格20。到了30天后，我用110元卖了100股股票。能拿到的钱是110*100 = 11000
      • 假如股价90。收支平衡。支出是20 * 100 + 90 * 100 = 11000。收入是11000
      • 假如股价89。那就赚了。盈利 11000 - 2000 - 8900 = 100
      • 假如股价91，那就亏了。亏9100 + 2000 - 11000 = 100

Short Covered Call

  • 如果我卖了1张30天的call。当前价格C 卖了S价格的call，价格P。盈利 (S+P-C)*100
    • 如果我卖了90元的call。价格25。那我可以拿到的钱是2500。买股票用了10000。
      • 假如股价90。那别人用9000来买我的这100股。我总共收到9000+2500=11500。赚了1500
      • 假如股价89。那别人就不会来买我的股票了。我拿到2500但是股价也变成了8900。所以是2500 + 8900 = 11400。赚了11400
      • 假如股价75。2500+7500=10000。不亏不赚 iv. 假如股价70。2500+7000=9500。亏了500
    • 如果我卖了110元的call，价格8。
      • 假如股价110。别人给我11000。我赚了 11000 +800 - 10000 = 1800
      • 假如股价92。不交割。我收支平衡。9200+800=10000
      • 假如股价90。不交割。9000+800=9800 我亏了 10000 - 9800 = 200

Short Put

  • 如果我卖了1张30天的Put。交割时价格C 交割价格S 卖了X价格的put，价格Y。盈利 (C-S+X) * 100
    • 如果我卖了90元的put。价格8块钱。
      • 假如股价82被结算。那我被强制买了100股90块钱的股票。但是算上卖put拿到的8块钱，每股就是82元。就是不亏不赚
      • 假如股价81。put被结算。那每股就亏了1块钱。
      • 假如股价83。put被结算。那每股就赚了1块钱。 iv. 假如股价91，那就不会结算。那就一共赚了800块钱。
    • 如果我卖了110元的的put。价格20。
      • 假如股价90是被结算，那我花了11000但是卖call拿到了2000，股票价值9000。等于不亏不赚
      • 假如股价89被结算，那每股就亏了1块钱
      • 假如股价91被结算，那每股就赚了1块钱
    • 假如股价111，那就不会被结算，就赚了卖put的钱2000。

期权交易中的各种策略

Date: 01/31/2021 Frank Gao

学习笔记 https://www.investopedia.com/trading/options-strategies/

Short covered call

首先购买100股某股票，假设价格是100元每股。这时候选择一个call的strike价格比如102元。这个call的价格假设是2元。这时用已经购买的股票作为保障，就可以卖一个covered call。别人会以200元的价格购买你的call。

  • 假设股票涨到了101。别人肯定不会行权，那不算股票最大的盈利就是200元。
  • 假设股票开始跌了，但是只跌到98元。这时候别人肯定不会行权。虽然股票的价格上我们跌了200，但是因为别人给了200。所以等于没赚没赔。
  • 假设股票跌到了97元。那等于亏了300 - 200 = 100元。这也比自己买一百股亏300元要好。

总结就是Short covered call可以用来对冲股票小跌的风险。

pros cons
马上拿到钱 最多盈利也固定了
相当于买股票的价格降了call价格，等于打折了

Short covered call

Married Put

首先会购买100股某股票。然后同时购买一个put来保护大跌的情况。

Married Put

Bull Call Spread

不买正股。在X价位买一个call的同时在X+Y的价位卖一个call。这两个call的过期时间相同。这样在大涨的时候就能盈利。

Bull Call Spread

Bear Put Spread

不买正股。在X价位买一个put然后在X-Y价位卖一个put。这两个put的过期时间相同。这样股票大跌的时候就能盈利。

Bear Put Spread

Protective Collar

这是在你有一百股的时候，比如股价cost是100刀。买一个95的put的同时卖一个105的call。这样可以保证股价就算大跌，损失也是稳定的。股价要是小涨，盈利也是有封顶的。这个策略的好处是大大的降低了风险，同时也保护了这100股，所以叫Protective Collar

Protective Collar

Long Straddle

不买正股。同时买入call和put在同一个strike price和同一个expire date。这是在预判价格会要么大涨要么大跌。

Long Straddle

Long Strangle

不买正股。在低位买一个put，在高位买一个call。这样买option的成本会低但是盈利平衡点也会扩大。只有在股票大涨或者大跌的时候才有可能盈利。

Long Strangle