On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: Limiting your involvement with Reddit, or Temporarily refraining from using Reddit Cancelling your subscription of Reddit Premium as a way to voice your protest. I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns. More on reddit.com

First of all you should be familiar with some HTTP methods, and basic terminology. API stands for Application Programming Interface. This may not tell you much on it’s own if you can’t solidify what application and programming interface means.

Well, defining application is easy and you can probably refer it yourself. Any one or many “programs” or functionality coming together to be used by an end-user towards a need or a purpose is an application.

The word interface in software is used as “an endpoint of an application that an end-user can interact with”, it’s short for human - software interaction. But there’s more to it when you generalize from a real example.

Say that you have loaded the search engine, Google’s homepage. You are met with an interface. So far, this interface has already served you a resource, the search form, logo and all. On it you notice it can possibly do more than just showing you a single page. There’s an input area, and a button. You type in your favorite network, Reddit, and click search. Conguratulations, you have just interacted with the interface, you’ve sent data to it. Now it returns you new resources, web pages that are listed based on your search term. You have now defined that “an interface helps you interact with resources by certain actions.”

You might have felt a bit constrained while using Google. Why the hell can’t you change some of the results or add your own into them? Well, that’s because you’re not authorized to do so. But worry not, an interface will also enable that, as long as you have the correct “passport” for it. You were interacting on Google’s interface at the public level, what you can do, anyone can.

A programming interface is only different at one end-point, you. It’s for different programs to interact with each other, not humans. To make this interaction process more universal, HTTP methods were introduced into web APIs. That “universal” behavior made what’s now called REST API. These API ends are usually token-authenticated, especially if they also allow operations besides retrieving data.

Now for the HTTP methods used in REST APIs. These are:

GET: Our good old, classic way to ask for a resource. This is what you did by loading Google’s homepage, and you didn’t notice it but when you searched with a keyword, you also did this to get the listings! (Like: GET /user/1 or GET /users)

PUT: This is like, exchanging your Pepsi for your friend’s Coca Cola (Sometimes it’s too late for your friend to notice that you don’t have a Pepsi).

In context, PUT replaces a resource completely, even if it doesn’t exist. So it also has a way of saying “replace that empty resource with a not-so-empty one”, meaning it can also create! But usually you’ll see POST being used for creation, PUT for updating. (PUT /user/1 or PUT /user if it’s an insert)

PATCH: You posted a comment on a regex replace question on r/learnpython, being silly you used “$1” for match replacement instead of “\1”. In quick shame, before people notice your Perl-syntax you edited and updated your comment, it was only a partial error you had to correct.

While PUT is for replacing a resource completely, PATCH is usually used to replace partial data. It is valid for existent resources, meaning unlike PUT it won’t create if there’s no such resource. This sad little thing is not as often used, due to POST/PUT preference over PUT/PATCH. (PATCH /user/1)

POST: You posted this thread, whee!~ It wasn’t here before, you created it, now you have a URL for it to reference as well, whether you want to see it again, edit it, or... (POST /user)

DELETE: ... delete it. You want this post gone? Sure, the post probably feels the same way! (DELETE /user/1)

In general, created resources return an id (resource identifier) for you, update and delete operations require such an id, for listing it can be optional. You can GET a specific resource with it’s identifier or refer to it’s container to get all the resources within it. REST APIs commonly communicate with either JSON or XML, mostly JSON nowadays.

If the word resource is too vague, it’s because it’s meant to be. A resource can literally be anything, but in general, it’s a/group of a data.

If you have any other questions, feel free to ask, I’ll be happy to answer them!

More on reddit.com

You've massively misunderstood the complexities that current REST models (with all overheads) solve. You claim to have been in the game long enough to have a decent top-down view on the situation, but you evidently weren't there (at a complex enough level) when CORS etc was brought in during the early days of REST patterns. It was a simple evolution of problems and solutions, one by one as problems and vulnerabilities in the design were discovered.....and it's still currently unmatched for that base communications model. Websockets and REST API solve different problems.... or occasionally different solutions to the same problem. Websockets are fine for a temporary connected session. REST is - by design - stateless. Because most APIs eventually require a stateless solution, it makes sense to implement a REST API in almost every case. Once you've done that, a websocket solution becomes an unnecessary additional duplication of functionality for a minor performance improvement. If you build a compatibility/requirement matrix between required functionality for your Web app and the website itself and the various other connected mobile apps and syndicated data operations talking to your backend....REST solves them all.....websockets solves a handful. More on reddit.com

Imagine you're at a library looking for a specific book. Unfortunately for you, this library is huge and the designers decided to give each book a number and lock all them all in a back room that you can't go in. So in order to get a book, you have to go to the front desk and ask the librarian for what you want. To make it easier to find what you're looking for, the librarian has a few different forms you can fill out to request what you're looking for. There's a form to get all the books by a specific author and there's a form to get a specific book, among others. So you go to the librarian and fill out the form for the book list by author. The librarian comes back with the list and you see the book you're looking for, it has a number of 123. So you grab a book form and write the number and give it to the librarian, and they come back with the book. That's an API. REST refers to the fact that you need to use forms to tell the librarian what you want, and each form is an entirely new process for the librarian. The librarian won't remember you were just asking for books by author xyz, they won't be able to do anything not on a form, and they can only let you give them one form at a time. Other kinds of APIs might let you have more interactive dialogue with the librarian, or allow you to call the librarian and ask them to send the book to your house whenever they find it, or give you access to the back room, and so on. More on reddit.com