Live data from Hacker News

Should we rebrand REST?

kieranpotts.com

111–120 of 154 posts

Re: Should we rebrand REST?

#111

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

As it is, REST is not standardized enough for automation.

It should be possible to generate a client library in any language just from the service's self-description.

Re: Should we rebrand REST?

#112

Earlier quoted context omitted.

Harded-coded URLs represent a larger API surface area. Hypermedia-driven APIs eg: HATEOAS permit the server to view URLs as an implementation detail. Some people and some problems benefit from APIs with large surface area. Some people and problems benefit from APIs with small surface area. I tend to like APIs with small surface areas because it means I don't have to drag along outdated endpoints across minor versions…

And another take on why clients being able to manually craft URLs is bad design: [0]. But prohibitting clients from manually constructing URLs really is not that hard: [1]. [1] https://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-h... [2] https://blog.ploeh.dk/2020/10/26/fit-urls/

From [1]

> In the future, I plan to make URLs opaque when building level 3 APIs. Instead of http://foo.ploeh.dk/customers/1234/orders, I'm going to make it http://foo.ploeh.dk/DC884298C70C41798ABE9052DC69CAEE .... Obviously, that means that my API will have to maintain some sort of two-way lookup table that can map DC884298C70C41798ABE9052DC69CAEE to a request for customer 1234's orders

I pity the people who had to work with him, and the many thousands of hours this has probably ended up costing.

Re: Should we rebrand REST?

#113

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.

The poetry of writing semantically meaningful urls is gone. We need really detailed descriptions of the interface boundary, who is responsible and how things are encoded, such that one can use any language they wish for either side of the call.

This problem has been solved before.

Re: Should we rebrand REST?

#115
post #112

Earlier quoted context omitted.

And another take on why clients being able to manually craft URLs is bad design: [0]. But prohibitting clients from manually constructing URLs really is not that hard: [1]. [1] https://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-h... [2] https://blog.ploeh.dk/2020/10/26/fit-urls/

From [1] > In the future, I plan to make URLs opaque when building level 3 APIs. Instead of http://foo.ploeh.dk/customers/1234/orders , I'm going to make it http://foo.ploeh.dk/DC884298C70C41798ABE9052DC69CAEE .... Obviously, that means that my API will have to maintain some sort of two-way lookup table that can map DC884298C70C41798ABE9052DC69CAEE to a request for customer 1234's orders I pity the people who had to…

Oh yeah, having a table with UUIDs instead of customer numbers for primary keys does waste many thousands of hours, that's why CQRS is also a terrible idea.

Re: Should we rebrand REST?

#116

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.

The article is in fact arguing that calling APIs RESTful is a category error.

REST is a standard for protocols implemented by APIs, not APIs themselves. WWW itself is RESTful, not WWW servers.

Re: Should we rebrand REST?

#117

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

It's pedantry indeed, but in this case the incorrect use of words actively confuses people, causes arguments, and wastes time.

You know this is the case whenever people are seriously considering references to the thesis as arguments.

Re: Should we rebrand REST?

#118
post #4

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned…

Unlike REST, HTTP is a well-defined standard.

Hypermedia APIs, on the other hand, are an active area of research, so it makes perfect sense for them not to be standardized yet. And once a specific standard does emerge, it will have a different name too, of course.

Re: Should we rebrand REST?

#119
post #16

Earlier quoted context omitted.

> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.

> I've officially banned the word "REST" from being used in technical discussions. So if I want to refer to the architecture of that name described in Fielding’s Architectural Styles and the Design of Network-based Software Architectures , what is the approved circumlocution?

I assume they mean REST as applied to APIs. The thesis is just not about APIs, as argued by the article.

Re: Should we rebrand REST?

#120

I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on! Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain. Just use Gra…

GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps. I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it... It's just professional negligence to suggest it's not more invol…

The 15 seconds and 10 lines of code you "loose" defining your graphQL schema saves you hours soon after, when you'll be fixing the problems created by poorly structured REST endpoint and endless debates.

With REST: I can build an endpoint and point it straight to a parameterized SQL query.

With GraphQL: I can build a resolver and point it straight to a parameterized SQL query.

So yes, I insist that it's overall much simpler to use GraphQL, having done both extensively.

Here is a GraphQL server in Python, (Note that it automatically provides documentation, a GraphQL interactive playground, Introspection, etc.). Do the same with Rest and tell me where the overhead is

    from ariadne import QueryType, make_executable_schema
    from ariadne.asgi import GraphQL
    from starlette.applications import Starlette

    type_defs = """
        type Query {
            projects(first: Int): [Project!]!
        }

        type Project {
            id:        Int
            name:      String
        }
    """

    query = QueryType()

    @query.field("projects")
    async def resolve_projects(_, info, first=10):
        query = projects.select().limit(first)
        results = await database.fetch_all(query)
        return results


    Starlette().mount(
        "/graphql",
        GraphQL(make_executable_schema(type_defs, query)),
    )

(It could be made even shorter with Graphene, but shorter != better in my opinion).
Post reply on HN