5 ms·

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters

by swax 11y ago

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel in the jar.

morgante 11y ago
You understand REST.
oldmanjay 11y ago
It seems like the only thing Dropbox doesn't have is the verbs. On the other hand, I've never much cared about the "no true REST" crap that the conversation always seems to turn into. I'm too pragmatic to care if I'm adhering to someone's concept of a convention.
BinaryIdiot 11y ago
You are apparently me. I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're RESTful...okay fine ONE RPC endpoint for the profile page's information. I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@
- dragonwriter 11y ago
  > Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. (You probably would want to have authoritative URLs for the subresources in the representation, assuming the media type of the representation is one which supports that.)
  - BinaryIdiot 11y ago
    > There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots". If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls. Google has an interesting solution for batch HTTP requests that could kinda be used in a way to batch RESTful requests but it's not the most intuitive. https://developers.google.com/drive/web/batch https://developers.google.com/drive/web/batch
    - dragonwriter 11y ago
      > Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots". The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition. Whatever is designed as part of that page, and is also a resource, is a subresource. > If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls. URLs align to resources in that the fact that a URL is used to access something defines it as a resource. There is nothing in REST which defines resources as only the orthogonal entities in a data mode (e.g., the loose equivalent of entities in the base tables of a relational DB model.) You certainly in many cases, for maximum flexibility, want your resources to include those kinds of things, but there is no reason -- at least none that has anything to do with REST -- for them to be limited to them.
      - BinaryIdiot 11y ago
        > The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition. > Whatever is designed as part of that page, and is also a resource, is a subresource. No that's not true at all. Your API design should not influence the user experience but the other way around and you're unlikely to change models should you have more optimal ways to presenting things. On paper? Sure but I've never seen anything able to be split so nicely as you describe.
- ericingram 11y ago
  I think we solved the common issues with REST for Schema (https://schema.io https://schema.io) in a way that makes it really nice for developing web apps. For example, to include related resources you can specify an `expand` field in a get request, and if you want to include unrelated resources you can do it with the `include` field. There are probably good ways to solve most if not all of the problems people typically run into with REST APIs for web apps, but it could take a lot of experimentation to figure them out. It sure took us a while.
aikah 11y ago
The problem with RPC style calls is you can't take advantage of "natural" server features like caching and such. You need to re-implement all this on top of both the client and the server. I agree with your point about REST though, it's not even a standard. If it was there would be no debate about what REST is and what it isn't. It's a vague set of idea and its author himself kind of said his paper was targeted at "specialists" and not classical "developers". People keep on telling me "read the spec", well there is no normative spec.
- smarx 11y ago
  FYI, endpoints that could actually take advantage of caching (e.g. downloading a file, preview, or thumbnail) do support HTTP GET with ETags.

by swax 11y ago

morgante 11y ago

You understand REST.

oldmanjay 11y ago

It seems like the only thing Dropbox doesn't have is the verbs. On the other hand, I've never much cared about the "no true REST" crap that the conversation always seems to turn into. I'm too pragmatic to care if I'm adhering to someone's concept of a convention.

BinaryIdiot 11y ago

You are apparently me. I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're RESTful...okay fine ONE RPC endpoint for the profile page's information. I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@

dragonwriter 11y ago
> Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. (You probably would want to have authoritative URLs for the subresources in the representation, assuming the media type of the representation is one which supports that.)
- BinaryIdiot 11y ago
  > There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots". If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls. Google has an interesting solution for batch HTTP requests that could kinda be used in a way to batch RESTful requests but it's not the most intuitive. https://developers.google.com/drive/web/batch https://developers.google.com/drive/web/batch
  - dragonwriter 11y ago
    > Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots". The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition. Whatever is designed as part of that page, and is also a resource, is a subresource. > If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls. URLs align to resources in that the fact that a URL is used to access something defines it as a resource. There is nothing in REST which defines resources as only the orthogonal entities in a data mode (e.g., the loose equivalent of entities in the base tables of a relational DB model.) You certainly in many cases, for maximum flexibility, want your resources to include those kinds of things, but there is no reason -- at least none that has anything to do with REST -- for them to be limited to them.
    - BinaryIdiot 11y ago
      > The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition. > Whatever is designed as part of that page, and is also a resource, is a subresource. No that's not true at all. Your API design should not influence the user experience but the other way around and you're unlikely to change models should you have more optimal ways to presenting things. On paper? Sure but I've never seen anything able to be split so nicely as you describe.
ericingram 11y ago
I think we solved the common issues with REST for Schema (https://schema.io https://schema.io) in a way that makes it really nice for developing web apps. For example, to include related resources you can specify an `expand` field in a get request, and if you want to include unrelated resources you can do it with the `include` field. There are probably good ways to solve most if not all of the problems people typically run into with REST APIs for web apps, but it could take a lot of experimentation to figure them out. It sure took us a while.

aikah 11y ago

The problem with RPC style calls is you can't take advantage of "natural" server features like caching and such. You need to re-implement all this on top of both the client and the server. I agree with your point about REST though, it's not even a standard. If it was there would be no debate about what REST is and what it isn't. It's a vague set of idea and its author himself kind of said his paper was targeted at "specialists" and not classical "developers". People keep on telling me "read the spec", well there is no normative spec.

smarx 11y ago
FYI, endpoints that could actually take advantage of caching (e.g. downloading a file, preview, or thumbnail) do support HTTP GET with ETags.