Why use an Accept header when you can do this, right?

randomapi.com/random/resource/json
randomapi.com/random/resource/xml

🤦‍♂️

I'm already feeling it, I'm gonna have a great time with this API

It would be nicer if it can accept token as a query param

nothing unusual here, far from the worst design in the world 🤔

Now, what would be actually bad is if /json returned XML, and /xml returned JSON. But that's not the case here. Or is it...

@asgs I'll hit you with my keyboard and make you choke on the keycaps

@hinst hopefully it isn't, haven't made any requests to it yet...

Sure, not the best design, but if their intention is for users to be able to just generate some dummy data quickly then being able to tell the API which format to use using the URL would allow them to link to the API and let the user open it in their browser.

@ScriptCoded good point, but it's not a dummy data generator, it's a ZIP code search engine, I just omitted the API's actual address.

@neeno Well then, then I'm all with you

You sound like you already know how the Accept header in an HTTP request is used. Specifying the format of the response data in the URL is a good example of terrible ideas if you're talking REST.

Let's create a GitHub repo with the worst API ideas in the world, kinda like
https://theworldsworstwebsiteever.com/...

Let's call it UNREST

@eo2875 honestly, I like the idea. However, I'm not gonna create the repo because I like my anonymity here on DevRant. But I do like a lot the idea.

I do that when I know I'll run out of standard content-types. Introducing custom ones just doesn't feel right.

Another thing with format in URL -- browser-friendly approach. Just pop that URL in your addressbar and there you have it.

What if that api later wants to offer slugs as route param?

Ima name that slug json (:

Defining an Accept header is a standard afaik :)

@eo2875 that site needs infinite scroll both horizontally and vertically to be truly the worst