RPC
Remote Procedure Calls (RPCs) allow developers to make function calls to a remote server as if it were on their local machine. RPCs hide the complexities of packing and sending function arguments to the remote server, receiving return values, and managing network retries.
RPC (Remote Procedure Call) is an interprocess communication protocol widely used in distributed systems. It spans the transport and application layers in the OSI model of network communication.When we use a remote procedure call, the calling environment that starts it stops what it's doing and sends information about the procedure to another service over the internet. The service then runs the procedure and sends back the results. Once the original computer gets the results, it starts running again like normal.
To do a remote procedure call, there are different parts on both the computer that starts it and the one that runs it. On the starting service, there is the program, a special part of the program called the "stub", and one part of the remote procedure call system. On the other service, there is the program that does the work, another "stub", and one part of the remote procedure call system.
The process of making a remote procedure call involves the following steps:
- A client initiates a client stub process by providing parameters as normal. The client stub is stored in the address space of the client.
- The client stub converts the parameters into a standardized format and packs them into a message. After packing the parameters into a message, the client stub asks the local RPC runtime to deliver the message to the server.
- The RPC runtime at the client delivers the message to the server over the network. After sending a message to the server, it waits for the message result from the server.
- The RPC runtime at the server receives the message and passes it to the server stub.
- The server stub unpacks the message, takes the parameters out of it, and calls the desired server routine using a local procedure call to execute the required operation.
- After the server routine executes with the given parameters, the result is returned to the server stub.
- The server stub packs the returned result into a message and sends it to the RPC runtime at the server on the transport layer.
- The server's RPC runtime returns the packed result to the client's RPC runtime over the network.
- The client's RPC runtime, which was waiting for the result, now receives the result and sends it to the client stub.
- The client stub unpacks the result, and the execution process returns to the caller at this point.
thrift
apache • Updated Aug 29, 2023
fbthrift
facebook • Updated Aug 30, 2023
Restful API
- GET /tickets - Retrieves a list of tickets
- GET /tickets/12 - Retrieves a specific ticket
- POST /tickets - Creates a new ticket
- PUT /tickets/12 - Updates ticket #12
- PATCH /tickets/12 - Partially updates ticket #12
- DELETE /tickets/12 - Deletes ticket #12
POST https://www.instagram.com/api/v1/feed/timeline/
GET https://www.instagram.com/api/v1/media/3089203147800857051/comments
Rest API Popular Endpoint Formats
https://api.example.com/v1/items
https://example.com/api/v1/items
Rest API Success Responses
1- GET - Get single item - HTTP Response Code: 200
HTTP/1.1 200
Content-Type: application/json
2- GET - Get item list - HTTP Response Code: 200
HTTP/1.1 200
Pagination-Count: 100
Pagination-Page: 5
Pagination-Limit: 20
Content-Type: application/json
3- POST - Create a new item - HTTP Response Code: 201
HTTP/1.1 201
Location: /v1/items/12
Content-Type: application/json
4- PUT - Update an item - HTTP Response Code: 200/204
If updated entity is to be sent after the update
HTTP/1.1 200
Content-Type: application/json
If updated entity is not to be sent after the update
HTTP/1.1 204
5- DELETE - Delete an item - HTTP Response Code: 204
HTTP/1.1 204
Rest API Error Responses
1- GET - HTTP Response Code: 404
HTTP/1.1 404
Content-Type: application/json
2- DELETE - HTTP Response Code: 404
HTTP/1.1 404
Content-Type: application/json
3- POST - HTTP Response Code: 400
HTTP/1.1 400
Content-Type: application/json
4- PUT - HTTP Response Code: 400/404
HTTP/1.1 400
Content-Type: application/json
HTTP/1.1 404
Content-Type: application/json
5- VERB Unauthorized - HTTP Response Code: 401
HTTP/1.1 401
Content-Type: application/json
6- VERB Forbidden - HTTP Response Code: 403
HTTP/1.1 403
Content-Type: application/json
7- VERB Conflict - HTTP Response Code: 409
HTTP/1.1 409
Content-Type: application/json
8- VERB Too Many Requests - HTTP Response Code: 429
HTTP/1.1 429
Content-Type: application/json
9- VERB Internal Server Error - HTTP Response Code: 500
HTTP/1.1 500
Content-Type: application/json
10- VERB Service Unavailable - HTTP Response Code: 503
HTTP/1.1 503
Content-Type: application/json
Validation Error Formats
Validation error formats can be different depending on your requirements. Following are some other popular formats, other than the one used above.
HTTP/1.1 400
Content-Type: application/json
HTTP/1.1 400
Content-Type: application/json
Other examples
Operations | Endpoints | Data Entities | Response |
Search | GET /v1.0/search?query={string} | Parameters are passed in the URL | 200 OK, Yes |
Sort | GET /v1.0/search?query={string}&sort={field}&order={ascending} | Parameters are passed in the URL | 200 OK, Yes |
Pagination | GET /v1.0/search?query={string}&skip={value}&limit={value} | Parameters are passed in the URL | 200 OK, Yes |
Recommendation | GET /v1.0/recommendations?query={string} | Parameters are passed in the URL | 200 OK, Yes |
Advertisement | GET /v1.0/ads?query={string} | Parameters are passed in the URL | 200 OK, Yes |
Versioning