5 ms·
I highly suggest you expose functionality through Graphql. It lets users send out an agent with a goal like: "Figure out how to do X" and because graphql has in
by sergiotapia 9mo ago
I highly suggest you expose functionality through Graphql. It lets users send out an agent with a goal like: "Figure out how to do X" and because graphql has introspection, it can find stuff pretty reliably! It's really lovely as an end user. Best of luck!
- _heimdall 9mo agoA proper REST API would also work without all the extra overhead of GraphQL. People may dislike XML, but it is easy to make a REST API with and it works well as an interface between computer systems where a human doesn't have to see the syntax.
- ako 9mo agoDepends mostly on efficiency: GraphQL (or Odata as a REST compliant alternative that has more or less the same functionality) provide the client with more controls out of the box to tune the response it needs. It can control the depth of the associated objects it needs, filter what it doesn't need, etc. This can make a lot of difference for the performance of a client. I actually like Odata more than GraphQL for this purpose, as it is REST compliant, and has standardized more of the protocol.
- raverbashing 9mo agoREST + Swagger I'd say
- virtue3 9mo agoSwagger is critical. The graphql schema.json is very very good at helping ai's figure out how to use the service. Swagger evens that advantage.
- _heimdall 9mo agoHow does Swagger help with REST though? By design, REST supports schemas and is self documenting, Swagger seems redundant.
- _heimdall 9mo agoWhy would you need Swagger with REST?
- spiderfarmer 9mo agoWhy would anyone need docs.
- _heimdall 9mo agoREST is self documenting. Edit: for down voters, I'd be curious why.
- jermaustin1 9mo agoI didn't downvote, but I'm thinking that you need endpoint discovery, bucket types, etc. Sure you could write a 1 page document describing the buckets at the root level, the relationships of the objects, etc., but why not let swagger do that for you at compile time?
- _heimdall 9mo agoI'm talking about actual REST here though, not RPC. Endpoint discover and typed schemas are core pieces of REST, we don't need Swagger or similar to fill in those gaps.
- electroly 9mo agoNot one of the downvoters, but I'd guess it's because this is only true with HATEOAS which is the part that 99% of teams ignore when implementing "REST" APIs. The downvoters may not have even known that's what you were talking about. When people say REST they almost never mean HATEOAS even though they were explicitly intended to go together. Today "REST" just means "we'll occasionally use a verb other than GET and POST, and sometimes we'll put an argument in the path instead of the query string" and sometimes not even that much. If you're really doing RPC and calling it REST, then you need something to document all the endpoints because the endpoints are no longer self-documenting.
- storystarling 9mo agoI tried this recently and found the token overhead makes it prohibitive for any non-trivial schema. Dumping the full introspection result into the context window gets expensive fast and seems to increase hallucination rates compared to just providing specific, narrow tool definitions.
- mmasu 9mo agoa friend (and colleague, disclaimer) pushed this recently to github. It passes data through a duck fb layer exactly to avoid context bloat: https://github.com/agoda-com/api-agent https://github.com/agoda-com/api-agent worth taking a look to see multiple approaches to the problem
- deleted 9mo ago[deleted]
- cpursley 9mo agoHasura is working on this approach: https://promptql.io https://promptql.io