RESTLESS ?? REST API

As an Integration developer, I Dealt With, soap APIs -Soap API services, the grand-father?? of services, and REST, the cool kid?? on the block. I have been involved in multiple API projects till now —building, designing, and sometimes just scratching my head

Inconsistent schemas, weird status codes, and messy endpoints—I've seen?? it all.

So, I just wanted to write a few tips for designing REST APIs I am not a guruji????, and these tips aren't permanent??, They're just bits I have picked up from tinkering with APIs. I am not an expert at REST APIs but think of it like a dance practice that makes our dance perfect.

I would share some code snippets that might make you laugh. If they look familiar, no worries! ?? We are all learning here.

Mastering the Mysteries of REST API

REST API Overview from W3Schools

REST API OVERVIEW LINK

HTTP has these action words: GET, POST, PUT, PATCH, and DELETE—pretty much the Avengers?? of web actions.

Understanding HTTP CRUD Actions

HTTP CRUD actions are fundamental operations used in web development to create, read, update, and delete resources on a server. These actions correspond to the standard HTTP methods: POST, GET, PUT/PATCH, and DELETE.

1. Create (POST)

POST method operation, often associated with the HTTP POST method, adds new data to the server. When a client sends a POST request to the server, it typically includes data in the request body. This data represents the resource to be created.

2. Read (GET)

The READ operation, associated with the HTTP GET method, is used to retrieve existing data from the server. When a client sends a GET request to the server, it requests specific information or a collection of resources.

Here, the client is retrieving information about the user with the ID 123 by sending a GET request to the /users/123 endpoint.

3. Update (PUT/PATCH)

The UPDATE operation is used to modify existing data on the server. It is commonly implemented using either the HTTP PUT or PATCH methods. PUT is used to completely replace the resource, while PATCH is used to apply partial modifications.

In this example, the client is updating the email address of the user with ID 123 by sending a PATCH request to the /users/123 endpoint with the new email address.

4. Delete (DELETE)

The DELETE operation, associated with the HTTP DELETE method, is used to remove existing data from the server.

Here, the client is deleting the user with ID 123 by sending a DELETE request to the /users/123 endpoint.

PUT??POST.

Summary

POST and PUT are key players in web development, allowing us to create and reshape digital content with ease. They are the architects of change in the vast landscape of the internet, shaping our digital world one request at a time

We must know the HTTP Error codes 1xx Informational:

• 100 Continue:?Request received and continuing process.
• 101 Switching Protocols:?The server agrees to switch to the protocol specified in the request.

2xx Success:

• 200 OK:?Request successful and response is ready.
• 201 Created:?Request successful and a new resource was created.
• 202 Accepted:?Request accepted for processing,?but not yet completed.
• 203 Non-Authoritative Information:?Returned information may not be the source.
• 204 No Content:?Request successful,?but no content to return.
• 205 Reset Content:?Clear the client-side view of the resource.
• 206 Partial Content:?Only part of the requested resource is returned.
• 207 Multi-Status:?Multiple responses for multiple linked resources.
• 208 Already Reported:?The server has already reported the status of the resource.
• 226 IM Used:?The server successfully used the?IM?resource identifier.

3xx Redirection:

• 300 Multiple Choices:?Several options for fulfilling the request.
• 301 Moved Permanently:?The resource has been permanently moved to a new location.
• 302 Found:?The resource was temporarily moved to a new location.
• 303 See Other:?Redirect to another resource specified in the Location header.
• 304 Not Modified:?The resource hasn't changed since the request was sent.
• 307 Temporary Redirect:?Same as 302,?but for HTTP 1.1.
• 308 Permanent Redirect:?Same as 301,?but for HTTP 1.1.

4xx Client Error:

• 400 Bad Request:?Syntax error in the request.
• 401 Unauthorized:?Access requires authentication.
• 402 Payment Required:?Payment is required for access.
• 403 Forbidden:?Access is denied.
• 404 Not Found:?Resource not found on the server.
• 405 Method Not Allowed:?The requested method is not supported for the resource.
• 406 Not Acceptable:?The server cannot produce a response acceptable to the client.
• 407 Proxy Authentication Required:?The Proxy server requires authentication.
• 408 Request Timeout:?The request took too long.
• 409 Conflict:?Request conflicts with an existing resource.
• 410 Gone:?Resource is gone permanently.
• 411 Length Required:?Content length is missing from the request.
• 412 Precondition Failed:?The precondition specified in the request failed.
• 413 Payload Too Large:?The request entity is too large.
• 414 URI Too Long:?Request-URI is too long.
• 415 Unsupported Media Type:?The media type in the request is not supported.
• 416 Range Not Satisfiable:?The requested range cannot be met.
• 417 Expectation Failed:?Expectation in the request failed.
• 418 I'm a teapot:?(RFC humor) Server refuses to brew coffee because it's a teapot.
• 421 Misdirected Request:?The request reached an incorrect server.
• 422 Unprocessable Entity:?The request format is correct,?but the content is invalid.
• 423 Locked:?Resource is locked.
• 424 Failed Dependency:?The previous request failed,?so this depends on it cannot be completed.
• 425 Too Early:?Precondition headers are used prematurely.
• 426 Upgrade Required:?The server requires the client to upgrade to a different protocol.
• 428 Precondition Required:?The request requires a precondition.
• 429 Too Many Requests:?The client has sent too many requests in a given time.

5xx Server Error:

• 500 Internal Server Error:?Unexpected error on the server.
• 501 Not Implemented:?The server doesn't support the requested functionality.
• 502 Bad Gateway:?The server received an invalid response from another server.
• 503 Service Unavailable:?The server is currently unavailable.
• 504 Gateway Timeout:?Server didn't receive a timely response from another server.
• 505 HTTP Version Not Supported:?The server doesn't support the HTTP version used in the request.
• 506 Variant Also Negotiates:?The server sent conflicting negotiation responses.
• 507 Insufficient Storage:?The server doesn't have enough storage.

Best Practices for Rest API Implementation

Use HTTPS Always: It's like wrapping your API in a digital hug with SSL. Plus, it cuts down on authentication drama with fancy access tokens using HTTP Basic Auth.

Hash those Passwords: Think of it as giving your passwords a secret disguise. Hackers might try, but they won't crack it! MD5, PBKDF2, bcrypt, SHA—pick your favorite password superhero.

?

Consider OAuth: It's like adding a VIP pass to your API party. OAuth 2.0 lets third-party apps sneak in, but only with your permission!

?

Validate Inputs: Think of it as a bouncer for your API club. Validate those request parameters right at the door before they cause any mischief inside.

Contact EasyStepIn for comprehensive #ipass cloud integration solutions leveraging top-tier tools Such as Boomi Workato Celigo SnapLogic