top of page
Search
  • Writer's pictureShannon

APIs Aren't Just For Devs Pt. 4 - HTTP Methods

This is my 50th blog post! I keep saying I need to blog more and am going to make a conscious effort to continue down this path! Happy 50 posts! Hopefully you're finding these posts interesting and are enjoying the content. My goal is to make tech easier to understand and break down these "headier" concepts into more manageable chunks of information! I have an RSS feed you can subscribe to and if we're connected on LinkedIn or Twitter, I'll post about these there!


So, REST API Methods...the next area of focus! If this is the first blog post you discovered in the series, please refer to the other blog posts here: APIs Aren't Just For Devs Pt. 1 - API Definition (shankuehn.io)


As I covered in the 2nd blog post, REST (REpresentational State Transfer) is an architectural style for designing networked applications. It uses a set of standard HTTP methods (also known as verbs) to perform CRUD (Create, Read, Update, Delete) operations on resources. These methods allow clients (such as web browsers or mobile apps) to interact with the server and manipulate data. Here are the main REST API methods:

  1. GET - The GET method is used to retrieve data from the server. When a client sends a GET request to a specific URL, the server returns the requested data if it exists. It is a safe and idempotent operation, meaning it should not have any side effects on the server, and multiple identical GET requests should produce the same result.

  2. POST - The POST method is used to create new resources on the server. When a client sends a POST request, it submits data to the server, which processes the data and creates a new resource. Each time the POST request is sent, it may lead to a different result, and hence it is not idempotent.

  3. PUT - The PUT method is used to update existing resources or create new resources if they don't already exist at the specified URL. When a client sends a PUT request, it includes the complete updated representation of the resource. If the resource doesn't exist, it creates one using the provided data. Like POST, it is not idempotent.

  4. PATCH - The PATCH method is used to apply partial updates to a resource. Instead of sending the complete updated representation of the resource, the client sends only the changes to be applied. The server then merges the changes with the existing resource. PATCH is not required to be idempotent, though it's good practice if it is.

  5. DELETE - The DELETE method is used to remove a resource from the server. When a client sends a DELETE request to a specific URL, the server removes the resource associated with that URL. Like GET, it is safe and idempotent since multiple DELETE requests on the same resource should have the same result as a single request.

These HTTP methods, when combined with resource URLs, allow developers to design RESTful APIs that follow the principles of statelessness, scalability, and uniformity. All of the above makes the API transaction/request/call easier to develop, maintain, and interact with. Proper use of these methods ensures that APIs are intuitive and align with the principles of RESTful design.

143 views0 comments

Recent Posts

See All

Enforcing Design Consistency with Azure Policy and Tags

Azure Policy allows you to create, assign, and manage policies in Azure (that definition feels a little like one of those awful definitions in Merriam Webster, right?). These policies enforce differen

Comments


bottom of page