Source: https://app.pluralsight.com/library/courses/designing-restful-web-apis/table-of-contents
I. Intro
- Fundamentals of HTTP and REST
- Designing the entire API
- Why versioning is so important
- Different security considerations
II. What is REST?
The history of distributed APIs
HTTP
How does HTTP work?
The request deconstructed
The response deconstructed
REST
What is REST?
- REpresentational State Transfer
- Separation of Client and Server
- Server Requests are Stateless
- Cacheable Requests
- Uniform Interface
III. Designing a RESTful API
Intro
- Designing the API First
- Nouns and Verbs
- URI Design
- Status Codes
- Designing Results
Design your API first
¿Por qué?
- Can't fix an API after publishing
- Too easy to add ad-hoc endpoints
- Helps understand the requirements
- Well-designed API can mature
REST APIs have several parts
- URIs are just paths to resources.
- Example: api.yourserver.com/people
API Design
- Nouns are good, and verbs are bad.
What are "resources"?
- Collections of nouns
- Complex objects
Identifiers in URIs
- Use unique identifiers
- Does not have to be "primary keys"
Query Strings
- Use for non-resource properties
- Format, sorting, searching, etc.
Design Verbs
- GET: Retrieve a resource
- POST: Add a new resource
- PUT: Update an existing resource
- PATCH: Update a resource with changes
- DELETE: Remove the existing resource
Idempotency in Action
- Operation that can be applied multiple times without changing the result
- Operations result in same side effect
- GET, PUT, PATCH and DELETE
- POST is not idempotent
Designing Results
- Members Names
- Shouldn't expose server details.
- I prefer camelCasing
- Designing Collections
Formatting Results
Hypermedia
- Allows results to be self-describing
- Allows programatic navigation
- Adds complexity
- Hypermedia ca be helpful, but pragmatism means that most projects don't need it.
IV. Handling more complex scenarios in your API
- abc
Versioning your API
- abc
Locking down your API
- abc
No comments:
Post a Comment