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/
{ "feed_items": [...], "more_available": true, "num_results": 5, "preload_distance": 4, "pull_to_refresh_window_ms": 5000, "request_id": "XXXXXXXXXXXXXXXXXXXX", "status": "ok" }
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
{ "id": 10, "name": "shirt", "color": "red", "price": "$23" }
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
[ { "id": 10, "name": "shirt", "color": "red", "price": "$123" }, { "id": 11, "name": "coat", "color": "black", "price": "$2300" } ]
3- POST - Create a new item - HTTP Response Code: 201
HTTP/1.1 201
Location: /v1/items/12
Content-Type: application/json
{ "message": "The item was created successfully" }
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
{ "id": 10, "name": "shirt", "color": "red", "price": "$23" }
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
{ "message": "The item does not exist" }
2- DELETE - HTTP Response Code: 404
HTTP/1.1 404
Content-Type: application/json
{ "message": "The item does not exist" }
3- POST - HTTP Response Code: 400
HTTP/1.1 400
Content-Type: application/json
{ "message": "Validation errors in your request", /* skip or optional error message */ "errors": [ { "message": "Oops! The value is invalid", "code": 34, "field": "email" }, { "message": "Oops! The format is not correct", "code": 35, "field": "phoneNumber" } ] }
4- PUT - HTTP Response Code: 400/404
HTTP/1.1 400
Content-Type: application/json
{ "message": "Validation errors in your request", /* skip or optional error message */ "errors": [ { "message": "Oops! The format is not correct", "code": 35, "field": "phoneNumber" } ] }
HTTP/1.1 404
Content-Type: application/json
{ "message": "The item does not exist" }
5- VERB Unauthorized - HTTP Response Code: 401
HTTP/1.1 401
Content-Type: application/json
{ "message": "Authentication credentials were missing or incorrect" }
6- VERB Forbidden - HTTP Response Code: 403
HTTP/1.1 403
Content-Type: application/json
{ "message": "The request is understood, but it has been refused or access is not allowed" }
7- VERB Conflict - HTTP Response Code: 409
HTTP/1.1 409
Content-Type: application/json
{ "message": "Any message that can help the user resolve the conflict" }
8- VERB Too Many Requests - HTTP Response Code: 429
HTTP/1.1 429
Content-Type: application/json
{ "message": "The request cannot be served due to the rate limit having been exhausted for the resource" }
9- VERB Internal Server Error - HTTP Response Code: 500
HTTP/1.1 500
Content-Type: application/json
{ "message": "Something is broken" }
10- VERB Service Unavailable - HTTP Response Code: 503
HTTP/1.1 503
Content-Type: application/json
{ "message": "The server is up, but overloaded with requests. Try again later!" }
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
{ "message": "Validation errors in your request", /* skip or optional error message */ "errors": { "email": [ "Oops! The email is invalid" ], "phoneNumber": [ "Oops! The phone number format is not correct" ] } } { "code" : 1024, "message" : "Validation Failed", "errors" : [ { "code" : 5432, "field" : "first_name", "message" : "First name cannot have fancy characters" }, { "code" : 5622, "field" : "password", "message" : "Password cannot be blank" } ] }
HTTP/1.1 400
Content-Type: application/json
{ "message": "Validation errors in your request", /* skip or optional error message */ "errors": { "email": [ { "message": "Oops! The email is invalid", "code": 35 } ], "phoneNumber": [ { "message": "Oops! The phone number format is incorrect", "code": 36 } ] } }
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