2024-02-12 11:22:36

This commit is contained in:
Isaac Shoebottom 2024-02-12 11:22:36 -04:00
parent 252d1e95a0
commit 581bdb2a4e
2 changed files with 103 additions and 6 deletions

View File

@ -13,7 +13,7 @@
"state": {
"type": "markdown",
"state": {
"file": "UNB/Year 4/Semester 2/STAT2593/2024-02-12.md",
"file": "UNB/Year 4/Semester 2/CS3103/2024-02-12.md",
"mode": "source",
"source": false
}
@ -85,7 +85,7 @@
"state": {
"type": "backlink",
"state": {
"file": "UNB/Year 4/Semester 2/STAT2593/2024-02-12.md",
"file": "UNB/Year 4/Semester 2/CS3103/2024-02-12.md",
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
@ -102,7 +102,7 @@
"state": {
"type": "outgoing-link",
"state": {
"file": "UNB/Year 4/Semester 2/STAT2593/2024-02-12.md",
"file": "UNB/Year 4/Semester 2/CS3103/2024-02-12.md",
"linksCollapsed": false,
"unlinkedCollapsed": true
}
@ -125,7 +125,7 @@
"state": {
"type": "outline",
"state": {
"file": "UNB/Year 4/Semester 2/STAT2593/2024-02-12.md"
"file": "UNB/Year 4/Semester 2/CS3103/2024-02-12.md"
}
}
},
@ -158,8 +158,8 @@
},
"active": "c6e1f6f3797edf57",
"lastOpenFiles": [
"UNB/Year 4/Semester 2/CS3103/2024-02-12.md",
"UNB/Year 4/Semester 2/STAT2593/2024-02-12.md",
"UNB/Year 4/Semester 2/CS3103/2024-02-12.md",
"UNB/Year 4/Semester 2/CS2333/2024-02-07.md",
"UNB/Year 4/Semester 2/CS3103",
"UNB/Year 4/Semester 2/CS3103.md",

View File

@ -1 +1,98 @@
Lecture Topic: Special In person Lecture
Lecture Topic: API Design
Special In person Lecture
# Web Services VS Web API
Network and Reusable
- Not libraries in the same app domain
- note one off custom integration
Two Broad categories
- Heavyweight, WS-* SOAP, WSDL
- Lightweight - HTTP, simple XML, or likely JSON
# REST
- Stateless - reduces complexity/ambiguity and improves scalability
- No need to re-hydrate endpoints for new server state information
- Representations used for manipulation - create, update, etc
- Identifies in request example.com/api/contact/7
- Standard HTTP verbs
- POST, GET, etc
- Proper response codes
- i.e, 200 for success, 400 for missing, 500 for server issue
# HTTP Verb Debate
Easy to classify:
Request/query should be GET
Delete should be DELETE
More Debate:
Creates should be POST
Update can be PUT or PATCH but you should implement PATCH
HTTP Method Responce Codes
| HTTP VERB | CRUD | ENTIRE COLLECTION <br>e.g. /customers/ | SPECIFIC ITEM <br>e.g. /customers/{id} |
| --------- | -------------- | ----------------- | ------------- |
| POST | Create | 201 | 404, 409 |
| GET | Read | 200 | 200, 404 |
| PUT | Update/Replace | 405 | 200, 204, 404 |
| PATCH | Update/Modify | 405 | 200, 204, 404 |
| DELETE | Delete | 405 | 200, 404 |
# Some Libraries and Payloads
- Custom JSON
- OData
- Started by Microsoft open source project, now OASIS
- not strictly REST
- JSON format standard for v4.0
- Discoverability - Service and metadata document
- Json:api
- JSON first
- Very verbose - but better than XML
- Hypermedia as the engine of application state (HATEOAS)
# Public, Partner, or Private APIs
Public:
- Exposed to the internet, can be paid or require verification
- Documentation
Partner:
- More for internal usage between organisations
- Still need good documentation
Private:
- Mostly for yourself, but can often become one of the other category
- Not worrying about breaking data formats or changing routes
- Documentation not required
# Who are you building for
- Apps, IoT
- Other Sites
- Things not thought of yet
Try to think what it will be called from (smartphone, script, desktop application, other services)
# Table Stakes
## Authentication
Maybe try and use 3rd party libraries to handle authentication (OAuth)
Think about what your service will be called from, think tokens for service/script APIs or token/username password authentication for desktop apps or smartphone applications
## Analytics/Metrics
You need to know what people are asking for and creating to know what to build in the future
- Performance Degradation - Rate Limiting
- Monetisation - See what people are asking for and limits on free vs should be paid users
# Good Problems and Unintended Uses
Good problems:
- Large client
- Super popular app
Unintended uses
- Internal API sold to a customer - Business people selling what was an internal API and now are being required to support the internal API
- Reporting/Analytics
- Bulk data export - How do you get 100 records, 1000 records
Should think about when you should using something other than a REST API, if the requirements grow past what a REST API can reasonably support
# Living Documentation
Postman - getpostman.com
OpenAPI/Swagger
Hootsuite's API as an example (link)
# Recommendations
APIs - A strategy guide