APIs Flashcards
What does REST stand for?
REpresentational State Transfer
What is REST?
REST is a ruleset that defines best practices for sharing data between clients and the server
What are the typical methods you use with a REST API?
You use CRUD functions only, regardless of the complexity. REST applications use HTTP methods like GET, POST, DELETE, and PUT.
Which architectural requirements need to be met for an API to be considered RESTful?
Client-server: REST applications have a server that manages application data and state. The server communicates with a client that handles the user interactions. A clear separation of concerns divides the two components. This means you can update and improve them in independent tracks.
Stateless: Servers don’t maintain client state, clients manage their own application state. The client’s requests to the server contain all the information required to process them.
Cacheable: servers must mark their responses as cacheable or not. Systems and clients can cache responses when convenient to improve performance. They also dispose of non-cacheable information, so no client uses stale data.
Uniform interface: This is REST’s most well-known feature or rule. Fielding says “The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.” REST services provide data as resources, with a consistent namespace.
Layered system: Components in the system cannot see beyond their layer. This confined scope allows you to easily add load-balancers and proxies to improve authentication security or performance.
What is the benefit of these architectural requirements?
They create an application with clear separations of concerns.
The client:
- receives server data when requested
- manipulates or displays the data
- notifies the server of any state changes
When would you NOT want to use REST?
Because all requests need to include all data to complete the request in the message payload, this can be restrictive. This works well when it we need a bit of data but quickly becomes unmanageable for complex requests.
