Another weird property of the devRant API:

For every POST request the url parameters need to be passed in the http body instead of in the URL, like this:
app=3&user_id=42

Wtf why?

Huh? That's probably possible, but it's not needed. I don't for example: https://molodetz.nl/retoor/...

I only do it for get requests. I have one method that prepares data, and sometimes that data is used in get sense (thus parameters) and sometimes in post sense. If it is a post, i do not send get parameters at all.

If devRant api allows you to put it in get, it's unexpected Ok-ish behavior or just a feature so that even crazy people who try this (like YOU :D) are able to use the API. They knew you would come some day. They knew in front what was going to happen maybe :P

They just allow both appearantly.

I consider the devrant api high quality. Only some consistency in field names could be better.

devRant uses what by now outdated tech as jQuery but in general devRant is a well written product. Also well designed. Trogus & Dfox is a great time. They are both great in their work for sure. Also barely maintenance. Good job.

@retoor no, both is not allowed. The api needs you to put the url params into the body if it‘s POST, otherwise you can put them into the url if it‘s GET or DELETE.
I haven‘t tried to always put them into the body but that‘s definitely unusual.
Url params belong in the url, not the body. They are encoded and escaped specifically for the url. I worked with a loooot of rest apis and never had one which required you to put url params into the body.

I have seen bad apis and good apis. DevRant isn‘t that bad but it definitely has some weird shit, like this one and the other one with the multitype value and the empty string, that I ranted about a few days ago.

Formdata?

@netikras
Content-Type: application/x-www-form-urlencoded
:)

Let’s see if I can post a comment with the new sdk…

Edit is buggy…
2

Edit test 1
2
Yasss! Works! (Was a UI problem)

Another annoying thing:

The response of the notification feed has a structure with dynamic keys (inside of username_map).
Those keys are the ids of the users.

Now I can‘t use a proper type for this because the properties are not known. I need to use a dictionary with string keys instead.

Another problem is that the user ids are normally integers but in this structure they are strings because they are json keys.

This is normally solved by structuring it differently: using an array and moving the keys into values for the same key, so that you can decode it in a type.

*sigh*

@Lensflare if course it's fine to have things like app_id json in in the body. Wtf? How's that unusable? The get request doesn't have a body of course. So that's the thing. Get requests of my api client do:

lalala?app_id=

and post do no query parameters and add it to body json:

{"app_id": 3, "rant_id": 3}

And that's not weird at all! It could've worked with a API token header. But it's perfectly rest and stuff.

@Lensflare you really thought i posted a query string in the body? Of course it's json. But it has the same source as the query parameters. How would I post my content then if that's already in the body? You craziii :P

.get("lala",params=prepare_auth({rant_id:3})) is get query

.post("lala",data=prepare_auth({rant_id:3})) is post query.

So as you can see, it used the same data (form prepare_ath) and the parameter to get/post defines if it's URL parameters or not.

This is pefectly fine and used as intended. You are the one who uses auth as query parameters in a post url. YOU are weird :P

@Lensflare you post data in body. You don't query, so query params make no sense. You post the data. In body

@retoor
It‘s absolutely fine to have url parameters with POST requests, I don‘t know why the devrant api tries to avoid it. It also allows (or requires) url params for DELETE, so why not for POST?

It would be fine if the params in the body would be json encoded, but they are url encoded. That‘s the weird part.
I haven‘t tried to json encode them but url encoded does work.

@netikras see my last comment :)

@Lensflare nah, sorry, it's really you making this weird assumptions. devRant does it fine, see my source code. It doesn't require auth as query parameters. Only for get request. For posts just goes json encoded in the body INSTEAD of query parameters. That's how mine works and how smth like that should work (if not working with API KEY header)

@Lensflare you just find smth weird that is possible and actually using it but don't have to at all.

@retoor ok my assumption that it requires url encoded params in the body might be wrong but I made this assumption for two reasons:

1. I stole it from OmerFlame

2. It works. Why would it work if it‘s not the intended way? 😅
That‘s a weird thing in itself.

Anyway thanks for letting me know that it works in any encoding.

But I stand by my point: There is nothing wrong in using url query params with POST, especially if you think that it‘s also ok for DELETE.

@retoor btw where did you get your infos from about how to use the API?

@Lensflare sure. But this is the pattern I've seen in many http client libs. And I think I saw it in rfc when I was trying to figure out why my http client won't allownpayloads for GET requests [ftr: not forbidden by rfc ;) ]

@netikras No, it's not forbidden because webdav does it. It describes details about what it wants to have. Webdav isn't much used anymore because of sftp. It actually had a lot of overhead. I've written my own server because it was mountable as hard drive on my file system and it goes over https securely. SSH does as well, but it's on a port that is blocked at some places. I can't be cool at starbucks with such limitaitons. (Just kidding, I live in a village where there's not even a pizza delivery guy).

Sadly, the webdav fuse client for mounting was bit low quality, end up not using it. But the project was amzing. Written in C.

@Lensflare on the streets, here and there. Well, it wasn't the worthless unofficial devrant api docs. Jesus christ. I WANTED THE API URL. NOT IN THOSE DOCS. AAAAAAAARGHH.

I stole from @feuerherz and account registration and downvoting i debugged from this website because nobody gave answers. That down voting i didn't see implemented correctly in any of the clients I've seen. I checked a lot and ended up writing my own, the best one there is for python. Literally. Not that's such a prestation, but it's sad that four of those projects exist and I had to make my own one. My drstats project does a thanks to a guy where I copied the basics from. Literally the basics.

Did you know there is a devRant C client? It's very minimal an doesn't even parse json but, well it's there. Not sure about quality.

I have written my own http client btw, faster than the python request library AND the aiohttp library. If i do 100.000 requests to a server, it can be ten seconds faster than aiohttp

@retoor sounds useless, ten seconds on 100.000 requests. But if you use it for IPC or smth, it's not bad.

A RELIEF FOR CRYPTO SCAM VICTIMS THROUGH SYNACK HACKERS

I understand the frustration and stress associated with lost funds through investment scams. They got me and did away with almost half a million dollars. Luckily, I have some influences around who introduced me to an organization called Synack Hackers. As specialists in crypto recovery, the team of expert professionals is dedicated to helping individuals and businesses reclaim their lost money lost to investment scams. With their proven track record and exceptional customer service, they are the go-to company for fund recovery in Montreal and beyond. We were able to track them down and got the complete amount. Reach out to Synack Hackers via the following contact information.

Email: (synackhack{@}tech{-}center{.}com)

Cool, I'll mail that loser (spammer above me). I'm also talking to another "hacker" about hacking a Facebook for fun but the loser doesn't check his spam folder. What hacker that is. I wonder why I got there now and not at the beginning. Scammers are such idiots, I always try to get scammed on purpose to figure out their scam but they still fail. Often I give tips about what they could do better. But some thank you? Nooo. Scammers are bastards.