5 ms·

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 t

by TekMol 1y 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=...

jaapz 1y 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.
- TekMol 1y ago
  Can you give an example of an endpoint where you would prefer a "RESTful API endpoint"?
- lelanthran 1y 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.
pbreit 1y ago
That’s pretty bad design. Only GETs should include a querystring. Links should only read, not create, update or delete.
- runeks 1y ago
  > Only GETs should include a querystring. Why?
  - sublinear 1y 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".
    - Gormo 1y ago
      Not a REST API, but I've found it particularly useful to include query parameters in a POST endpoint that implements a generic webhook ingester. The query parameters allow us to specify our own metadata when configuring the webhook events in the remote application, without having to modify our own code to add new routes.
    - runeks 1y ago
      What does that have to do with query parameters in non-GET requests?
Scarblac 1y ago
If you type it into the URL bar, it will use GET. Surely you're not advocating mutating data with GET?
- TekMol 1y ago
  What's your problem with it?
  - Pooge 1y 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.
    - TekMol 1y ago
      If you rely on the HTTP method to authenticate users to mutate data, you are completely lost. Bots and humans can send any method they like. It's just a string in the request. Use cookies and auth params like HN does for the upvote link. Not HTTP methods.
      - Pooge 1y ago
        > If you rely on the HTTP method to authenticate users to mutate data, you are completely lost I don't know where you are getting that from but it's the first time I've heard of it. If your link is indexed by a bot, then that bot will "click" on your links using the HTTP GET method—that is a convention and, yes, a malicious bot would try to send POST and DELETE requests. For the latter, this is why you authenticate users but this is unrelated to the HTTP verb. > Use cookies and auth params like HN does for the upvote link If it uses GET, this is not standard and I would strongly advise against it except if it's your pet project and you're the only maintainer. Follow conventions and make everyone's lives easier, ffs.
      - imtringued 1y ago
wraptile 1y 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.
thaumasiotes 1y ago
You're going to run into all kinds of security issues if you let GET endpoints have side effects.

by TekMol 1y ago

jaapz 1y 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.

TekMol 1y ago
Can you give an example of an endpoint where you would prefer a "RESTful API endpoint"?
lelanthran 1y 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.

pbreit 1y ago

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

runeks 1y ago
> Only GETs should include a querystring. Why?
- sublinear 1y 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".
  - Gormo 1y ago
    Not a REST API, but I've found it particularly useful to include query parameters in a POST endpoint that implements a generic webhook ingester. The query parameters allow us to specify our own metadata when configuring the webhook events in the remote application, without having to modify our own code to add new routes.
  - runeks 1y ago
    What does that have to do with query parameters in non-GET requests?

Scarblac 1y ago

If you type it into the URL bar, it will use GET. Surely you're not advocating mutating data with GET?

TekMol 1y ago
What's your problem with it?
- Pooge 1y 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.
  - TekMol 1y ago
    If you rely on the HTTP method to authenticate users to mutate data, you are completely lost. Bots and humans can send any method they like. It's just a string in the request. Use cookies and auth params like HN does for the upvote link. Not HTTP methods.
    - Pooge 1y ago
      > If you rely on the HTTP method to authenticate users to mutate data, you are completely lost I don't know where you are getting that from but it's the first time I've heard of it. If your link is indexed by a bot, then that bot will "click" on your links using the HTTP GET method—that is a convention and, yes, a malicious bot would try to send POST and DELETE requests. For the latter, this is why you authenticate users but this is unrelated to the HTTP verb. > Use cookies and auth params like HN does for the upvote link If it uses GET, this is not standard and I would strongly advise against it except if it's your pet project and you're the only maintainer. Follow conventions and make everyone's lives easier, ffs.
    - imtringued 1y ago

wraptile 1y 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.

thaumasiotes 1y ago

You're going to run into all kinds of security issues if you let GET endpoints have side effects.