Spoofing POST/GET requests in a RESTful service

My question is what prevents users from intercepting their regular post form the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does.

Nothing

Does the fact that the traffic to the service will eventually go via TLS make this a non-issue?

This makes no difference at all.

What are some possible ways from protecting from this?

The most common one is rate limiting. I.e. if someone posts at a much higher level than anticipated reject the post. There are several approaches to this - when did they last post, rolling average over N minutes etc. If you don't want false positives resulting in users losing post content then make them re-authenticate to continue.

Another approach is captchas. I.e trying to make the user prove they are human.

Another is attempting to detect automatically generated content using spam filters or AI.

My question is what prevents users from intercepting their regular post form the app

Nothing.

Does the fact that the traffic to the service will eventually go via TLS make this a non-issue?

If you make it for an mobile platform (Android/iOS), that makes it much harder (but not impossible).

If you make it for the browser, this doesn't add much protection.

What are some possible ways from protecting from this?

It is hard to protect against automatic requests, but one thing you could do is rate limit.

My question is what prevents users from intercepting their regular post from the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does.

What are some possible ways from protecting from this?

You don't. That is, you don't protect against this - from the perspective of authentication and authorization, there's no attack happening here, just perfectly legitimate traffic.

The problem instead is "How do I prevent users from spamming my service?" (or similar), and that's completely orthogonal to the question of authentication tokens. A user could similarly spam things manually through the app.

Rate limiting by user account, rate limiting by IP address, using cookies or device identifiers to tie multiple accounts together to rate limit by device, terms of blacklists, heuristics for spam, etc. are all common methods to deal with spam. But whatever your actual thing is that you're trying to prevent, that's what you should be looking into, not preventing users from modifying things client-side (which they will always be able to do).