4 ms·

I’ve seen the best REST APIs since Claude Code has taken the wheel Every verb implemented, and implemented correctly according to the obscure IETF and most com

I’ve seen the best REST APIs since Claude Code has taken the wheel Every verb implemented, and implemented correctly according to the obscure IETF and most compatible way when the IETF never made it clear Intuitively named routes, error, authentication all easily done and swappable for another if necessary I feel like our timeline split if you’re not seeing this

jwpapi 6mo ago
I don’t want every verb implemented, I also dont want an IETF standard. I want as little as possible, so I have to worry about as little as possible in the future. Use-cases differ, you described a complete REST API, which can be as much of a problem as a too little.
- hnuser123456 6mo ago
  I see you haven't encountered an API where a GET command can modify the database.
  - adithyassekhar 6mo ago
    Now why would you make such a monstrosity? Audit logs? I was having good day till now.
  - asa400 6mo ago
    Similarly, I once worked somewhere that had an HTTP API that returned status code 200 {“error”: “ok”} to indicate an error occurred.
    - Schiendelman 6mo ago
      A lot of GraphQL APIs are like this! They return a 200 just to mean the damn GraphQL is well formed, and the call can totally fail underneath.
  - ditchfieldcaleb 6mo ago
    Say what now
  - IshKebab 6mo ago
    I have not either. What's your point? AI isn't perfect.
  - esafak 6mo ago
    I saw a code base where SQL UDFs were used to mutate the data with SELECTs...
- yieldcrv 6mo ago
  Then just tell it to do that It'll even suggest it You want a single RPC websocket go for it
  - jwpapi 6mo ago
    Till it has explored the codebase, asked me follow up questions, suggested the code change, incorporating my fixes after losing time on context switch + the extra time I need when somebody requests a change in 3 months to learn the mental model. I’m way faster to just write it myself (mental model included)
    - phpnode 6mo ago
      If it's genuinely the case that you can write code faster than you can prompt it into existence then you're not being ambitious enough with your coding agent. Ask it to do more. Tackle bigger problems.
      - batshit_beaver 6mo ago
        1. It's unclear why creating more code faster is a good thing. Software engineering wisdom for decades has been that code is a cost, not a product. There are great reasons for that, which haven't changed with the appearance of LLMs. 2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code. One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building"). There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.
theteapot 6mo ago
the obscure IETF? Which standard is that exactly? Who cares guess - Claude do that stuff.
- yieldcrv 6mo ago
  I've tried to implement REST to its exact specifications before, turns out less common verbs like DELETE isn't implemented the same way across platforms and libraries because the IETF never specified. This means no standardization regarding having variables in the path vs the body vs headers, with some libraries or even OS level recognition preventing that, while the server may be looking for it this incongruence pushes people back to using just GET and POST methods in flexible and overloaded ways Agentic engineering knows all the best practices and ways to get around these limitations in the most compatible way and cranks out full APIs with all the verbs

jwpapi 6mo ago

I don’t want every verb implemented, I also dont want an IETF standard. I want as little as possible, so I have to worry about as little as possible in the future. Use-cases differ, you described a complete REST API, which can be as much of a problem as a too little.

hnuser123456 6mo ago
I see you haven't encountered an API where a GET command can modify the database.
- adithyassekhar 6mo ago
  Now why would you make such a monstrosity? Audit logs? I was having good day till now.
- asa400 6mo ago
  Similarly, I once worked somewhere that had an HTTP API that returned status code 200 {“error”: “ok”} to indicate an error occurred.
  - Schiendelman 6mo ago
    A lot of GraphQL APIs are like this! They return a 200 just to mean the damn GraphQL is well formed, and the call can totally fail underneath.
- ditchfieldcaleb 6mo ago
  Say what now
- IshKebab 6mo ago
  I have not either. What's your point? AI isn't perfect.
- esafak 6mo ago
  I saw a code base where SQL UDFs were used to mutate the data with SELECTs...
yieldcrv 6mo ago
Then just tell it to do that It'll even suggest it You want a single RPC websocket go for it
- jwpapi 6mo ago
  Till it has explored the codebase, asked me follow up questions, suggested the code change, incorporating my fixes after losing time on context switch + the extra time I need when somebody requests a change in 3 months to learn the mental model. I’m way faster to just write it myself (mental model included)
  - phpnode 6mo ago
    If it's genuinely the case that you can write code faster than you can prompt it into existence then you're not being ambitious enough with your coding agent. Ask it to do more. Tackle bigger problems.
    - batshit_beaver 6mo ago
      1. It's unclear why creating more code faster is a good thing. Software engineering wisdom for decades has been that code is a cost, not a product. There are great reasons for that, which haven't changed with the appearance of LLMs. 2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code. One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building"). There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.

theteapot 6mo ago

the obscure IETF? Which standard is that exactly? Who cares guess - Claude do that stuff.

yieldcrv 6mo ago
I've tried to implement REST to its exact specifications before, turns out less common verbs like DELETE isn't implemented the same way across platforms and libraries because the IETF never specified. This means no standardization regarding having variables in the path vs the body vs headers, with some libraries or even OS level recognition preventing that, while the server may be looking for it this incongruence pushes people back to using just GET and POST methods in flexible and overloaded ways Agentic engineering knows all the best practices and ways to get around these limitations in the most compatible way and cranks out full APIs with all the verbs