Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to (and how not to) design REST APIs

github.com

Post reply on HN
Print view View original

131–140 of 153 posts

Re: How to (and how not to) design REST APIs

#131

Post by rileymat2 »

pmontra wrote: post #130
jameshart wrote: post #127

Earlier quoted context omitted.

That’s what 302 responses are for. REST does not mean ‘parameters in the path not in the query string’.

I don't understand. Suppose that we have /shops/1/listing/1 /shops/2/listing/1 where listing 1 is an id local to those shops, they are two different listings. What happens to those URLs when those shops remove those listings? Both of them should return 404. Then the listing appears in shops 3 and 4. /shops/3/listing/1 /shops/4/listing/1 If we have four different records in the listings table of the database there is…

I don’t know if it is a usecase for etcy.. but In the first scenario doesn’t it make having different prices for a listing easier, because you will have a “shop item” table where you tell the system which items are in which shop, and can attach shop specific info.

So you have: |shopid|listingid|itemid|

The item is global and the listing is local to add shop specific info, or even whether that shop carries that item?

Of course this might not be a valid use case or I may misunderstand then meaning of listing.

Re: How to (and how not to) design REST APIs

#132

Post by [deleted] »

Arch-TK wrote: post #85
tkiolp4 wrote: post #39

Earlier quoted context omitted.

The vast majority of people using REST do not follow its original definition, so the original definition doesn’t matter anymore. It’s like human languages: REST is whatever we make of it, regardless of what academics say.

Sure. But then what words do you use to describe actual REST? This keeps happening and all it does it cause confusion. It's one thing to make up new words for new concepts so you can more easily refer to them in a conversation. It's another thing entirely to give a word a vague but similar meaning without any clear way to differentiate between the original specific and new extremely nebulous concept.

[deleted]

Re: How to (and how not to) design REST APIs

#133

Post by mablopoule »

gensym wrote: post #26

> REST APIs "You keep using that word. I do not think it means what you think it means". https://ics.uci.edu/~fielding/pubs/dissertation/top.htm

You might point out what "true REST" means based on the Fielding's paper, but at this point a "REST API" has a (somewhat) clear meaning derived from 2 decades of widespread usage to mean exactly what the author used it for.

I love etymology in general, but don't fall into the trap of thinking that the origin of a word or an expression is the only correct meaning.

Re: How to (and how not to) design REST APIs

#137

Post by DSMan195276 »

layer8 wrote: post #62
DSMan195276 wrote: post #35

Earlier quoted context omitted.

> Anything in your stack can return any HTTP error code - I don't see why 404 is special. I'm surprised you don't - in my experience 404's are by far the most common response to get when you haven't wired things up correctly. Sure anything in the stack _can_ return any code and response they want, but you're still much more unlikely to come across a 410 rather than 404. If that unlikeliness saves you support calls do…

With REST 404s due to missing resources (non-existing ID), you should generally get corresponding error information in the body (as also described in TFA), and clients should log/display that information. That should make enough of a difference. There’s a lot of “should” here, of course, but instead of teaching developers to not use 404, it would be better to teach them to create and handle error responses appropriat…

I really feel like you're ignoring the whole point, which is that this is about helping you out when things go wrong. Yes, it'd be great if we could teach people to never write bugs and that they should always check the response body, but that's just not what happens in reality. Being able to immediately differentiate the problem based on the response code is very useful when you get a bug submitted from someone saying they get a 404 and it doesn't work.

Re: How to (and how not to) design REST APIs

#139

Post by recursivedoubts »

cxr wrote: post #129
recursivedoubts wrote: post #101

Earlier quoted context omitted.

sorry, an hypermedia

That's not the problem. It's similar to the effect of a garden path sentence: when I encounter the word "a" and then "hypermedia", I'm always expecting something to follow (e.g. "a hypermedia system ", "a hypermedia format ", etc). Encountering "hypermedia" as a singular noun makes me wince. (The effect isn't ameliorated by modifiers, e.g. "a natural hypermedia".)

oh, sorry!

an hypermedium

Re: How to (and how not to) design REST APIs

#140

Post by dimator »

pmontra wrote: post #118
cxr wrote: post #98

Earlier quoted context omitted.

I'm on your side, but every time you say "a hypermedia" it kills me.

I'm not a native English speaker so, honest question: isn't h a consonant with its own distinct sound, so a instead of an?

It depends on the sound of the h. "A house" vs "an honor"
Post reply on HN