3. How Does Your API Work? Flashcards
What are the two parts that every HTTP request and response have?
The headers and the payload.
What is a HTTP request or response’s payload?
HTML, JSON, XML…
What range of HTTP response codes indicate that the request was successful?
2xx
What does the 2xx HTTP response code series indicate?
That the request was successful.
What does the HTTP response code 200 mean?
It simply means “OK.”
What does the HTTP response code 201 mean?
It means “Created.”
What does the HTTP response code 202 mean and what is it used for?
It means “Accepted.” It’s used for identifying that the action the user just performed is underway, but it’s not complete yet.
What does the HTTP response code 204 mean, and when is it primarily used?
It means “No Content.” It’s primarily used when deleting a resource.
What does the 3xx HTTP response code series indicate?
That the resource has been moved from its original URL.
What does the HTTP response code 301 mean?
It means “Moved Permanently” as in what you’re looking for is no longer available here. Most responsible APIs will then give you the URL to then retrieve it.
What does the HTTP response code 302 mean?
It means “Moved Temporarily.”
What does the 4xx HTTP response code series indicate?
That a client error has occurred.
What does the HTTP response code 400 mean and what does it indicate?
It means “Bad Request,” denoting that the most recent attempt failed due to the client itself.
What does the HTTP response code 401 mean and what does it indicate?
It means “Unauthorized,” which indicates that the required authentication credentials were not provided or the authentication has failed.
What does the HTTP response code 403 mean and what does it indicate?
It means “Forbidden,” which indicates that the user making the request is not authorized to access the API point that’s being requested.
What does the HTTP response code 403 mean and what does it indicate?
It means “Not Found,” which indicates that the resource you’re looking for does not exist.
What does the Content-Type HTTP header identify?
The type of the payload being provided by the server.
Are you required to follow the six constraints of RESTful API?
No. They are not hard and fast requirements but are good design principles you should follow.
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What is stateless architecture and what does it allow for each request?
It’s an architectural constraint of RESTful API that states that the API should be stateless. This allows each and every request to stand on its own and be processed or rejected independently of any other request in any order that they’re received.
What is client-server architecture and what is its biggest benefit?
It’s an architectural constraint of RESTful API that states that the API should be designed for a client-server architecture. The biggest benefit of this is that it allows us to vary the implementation details, upgrade paths, and scalability of each independently of the other.
What are the characteristics/benefits of a stateless architecture for HTTP requests/responses.
- Inherent to the design of the internet
- Stability
- Scalability
- Reliability
- Flexibility
What is cacheability mean in the context of RESTful API architecture and what does it require?
It’s an architectural constraint of RESTful API that deals with whether a response pair can be cached. It requires that each message describes whether it can be cached and if so, for how long.
What is the benefit of cacheability?
It allows the API to know when it’s possible to just return the result, instead of doing the work. This improves network performance and application usage overall.
What does idempotency mean in the context of cacheable API requests?
It means that whether we execute the command 1 or N+1 times, the state of the server is exactly the same.
What HTTP requests should we strive to make idempotent, and what ones are tricky in regards to this?
-
GET,PUT, andDELETEcan and should be idempotent.
2. POST is tricky. Since it can create or change the state, sometimes it’s idempotent but oftentimes it’s not.
What do layered systems mean in the context of RESTful API architecture?
It means that a given component might or might not communicate with another component and that your client should not be built with the assumption that it’s communicating directly with the server. There can and often will be additional layers between the client and the server itself.
What are the characteristics of layered systems?
- They are how the web is built
- Counting on direct connections/interactions adds silent, hidden dependencies, which is not the case with layered systems
- Allow us to add DNS lookups, load balancers, caching servers, logging, audit trails, authentication, and authorization
- Layers give us flexibility to improve and evolve our system as our requirements and the architecture changes.
What is “Code on Demand” in the context of RESTful API architecture?
It means that a request doesn’t just retrieve a resource, but also the code to act upon it and that the client doesn’t have to know what is in the code, it just has to understand how to execute the code.
What are the benefits of Code on Demand?
- Flexibility
- Upgradability
- Extensibility
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What are the six architectural constraints of RESTful API?
- Client-Server Architecture
- Stateless Architecture
- Cacheability
- Idempotency
- Code on Demand
- Uniform Interfaces
What are the four principles that make up a uniform interface?
- Identification of resources.
- Manipulation of resources through these representations.
- Self-descriptive messages.
- Hypermedia as the engine of application state (HATEOAS)
What does the “identification of resources” dictate in the context of designing uniform interfaces?
each resource should be uniquely addressable by a particular URL (though not a hard and fast requirement).
What does “manipulation of resources through these representations” dictate in the context of designing uniform interfaces?
That every interaction with a given resource should happen through the identifier (endpoint) that we already gave it.
What does “self-descriptive messages” dictate in the context of designing uniform interfaces?
That the messages should be standalone with their own processing and caching information, allowing us to create and use different types of messages very simply. This means that our client only needs to know how to retrieve and execute those instructions like the JavaScript code on demand that we see on the internet.
What does “hypermedia as the engine of application state” dictate in the context of designing uniform interfaces?
HATEOAS dictates that instead of users having to go to the documentation for what’s available, each and every link must be provided to them through the API (think choose-your-own-adventure books).
What is the biggest benefit of hypermedia as the engine of application state?
HATEOAS allow our apps to discover links. In effect, our apps don’t have to know every link in advance. Instead, they must know only how to discover them.
