← Back to context

Comment by TekMol

3 days ago

You know what type of API I like best?

    /draw_point?x=7&y=20&r=255&g=0&b=0
    /get_point?x=7&y=20
    /delete_point?x=7&y=20

Because that is the easiest to implement, the easiest to write, the easiest to manually test and tinker with (by writing it directly into the url bar), the easiest to automate (curl .../draw_point?x=7&y=20). It also makes it possible to put it into a link and into a bookmark.

This is also how HN does it:

    /vote?id=44507373&how=up&auth=...

30 comments

TekMol

Reply
jaapz  3 days ago

This is great for API's that only have a few actions that can be taken on a given resource.

REST-API's then are especially suited for acting as a gateway to a database, to easily CRUD and fetch lists of information.

The best API's I've seen mix and match both patterns. RESTful API endpoints for data, "function call" endpoints for often-used actions like voting, bulk actions and other things that the client needs to be able to do, but you want the API to be in control of how it is applied.

  • lelanthran  3 days ago

    > REST-API's then are especially suited for acting as a gateway to a database, to easily CRUD and fetch lists of information.

    I don't disagree, but I've found (delivering LoB applications) that they are not homogenous: The way REST is implemented, right now, makes it not especially suitable for acting as a gateway to a database.

    When you're free of constraints (i.e. greenfield application) you can do better (ITO reliability, product feature velocity, etc) by not using a tree exchange form (XML or JSON).

    Because then it's not just a gateway to a database, it's an ill-specified, crippled, slow, unreliable and ad-hoc ORM: it tries to map trees (objects) to tables (relations) and vice versa, with predictably poor results.

  • TekMol  3 days ago

    Can you give an example of an endpoint where you would prefer a "RESTful API endpoint"?

Scarblac  3 days ago

If you type it into the URL bar, it will use GET.

Surely you're not advocating mutating data with GET?

  • TekMol  3 days ago

    What's your problem with it?

    • Scarblac  3 days ago

      Bots, browsers that preload URLs, caching (both browser and backend and everything in between), the whole infrastructure of the Web that assumes GET never mutates and is always safe to repeat or serve from cache.

      Using GET also circumvents browser security stuff like CORS, because again the browser assumes GET never mutates.

      12 replies →

    • Pooge  3 days ago

      That any bot crawling your website is going to click on your links and inadvertently mutate data.

      Reading your original comment I was thinking "Sure, as long as you have a good reason of doing it this way anything goes" but I realized that you prefer to do it this way because you don't know any better.

      4 replies →

pbreit  3 days ago

That’s pretty bad design. Only GETs should include a querystring. Links should only read, not create, update or delete.

  • runeks  3 days ago

    > Only GETs should include a querystring.

    Why?

    • sublinear  3 days ago

      Because HTTP is a lot more sophisticated than anyone cares to acknowledge. The entire premise of "REST", as it is academically defined, is an oversimplification of how any non-trivial API would actually work. The only good part is the notion of "state transfer".

      1 reply →

wraptile  3 days ago

I used to do that but I've been fully converted to REST and CRUD gang. Once you establish the initial routes and objects it's really easy mount everything else on it and move fast with changes. Also using tools like httpie it's super easy to test anything right in your terminal.