501–510 of 580 posts
Earlier quoted context omitted.
How does the UI check if certain operations are available?
OPTIONS https://datatracker.ietf.org/doc/html/rfc2616 More links here: https://news.ycombinator.com/item?id=44510745
Earlier quoted context omitted.
When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…
Brb, I'm off to invent another language independent IDL for API definitions that is only implemented by 2 of the 5 languages you need to work with. I'm joking, but I did actually implement essentially that internally. We start with TypeScript files as its type system is good at describing JSON. We go from there to JSON Schema for validation, and from there to the other languages we need.
Watch out, OpenAPI is now 3 versions deep and supports both JSON and YAML.
Earlier quoted context omitted.
You can mess up grpc just as much. Errors are a good place to start.
Wait until you hear about errors in REST...
Earlier quoted context omitted.
Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…
> Fielding won the war It’s a bit odd to say fielding “won the war” when for years he had a blog pointing out all the APIs doing RPC over HTTP and calling it REST. He formalised a concept and gave it a snappy name, and then the concept got left behind and the name stolen away from the purpose he created it for. If that’s what you call victory, I guess Marx can rest easy.
I'm not sure the "name was stolen" or the zealot concept actually never got any traction in production environments due to all the problems it creates.
Earlier quoted context omitted.
> There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards Care to list them? REST mania started around early 2000-s, and at that time there was only CORBA available as a cross-language portable RPC. Microsoft had DCOM. And that was it. There was almost nothing else. It was so bad that ZeroC priced their ICE suite based on a PERCENTAGE OF GROSS SALES: h…
> Care to list them? From the top of my head, OData. https://www.odata.org/
Of course, REST won handily. We're not in this environment anymore, thankfully, and REST now is getting some well-deserved scrutiny.
Earlier quoted context omitted.
It's always better to use GET/POST exclusively. The verb mapping was theoretical from someone who didn't have to implement. I've long ago caved to the reality of the web's limited support for most of the other verbs.
What is the limited support for CONNECT/HEAD/OPTIONS/PUT/DELETE ?
Earlier quoted context omitted.
Or probably just an Allow header on a response to another query (e.g. when fetching an object, server could respond with an Allow: GET, PUT, DELETE if the user has read-write access and Allow: GET if it’s read-only).
That’s a neat idea actually, I think I’ll need to read up on the semantics of Allow again…. There is no reason you couldn’t just include it with arbitrary responses, no?
Earlier quoted context omitted.
The point of status codes is to have a standard that any client can understand. If you have a load balancer, the load balancer can unhealthy backends based on the status code. Similarly if you have some job scheduler or workflow engine that's calling your API, they can execute an appropriate retry strategy based on the status code. The client in most cases does not care about why something failed, only whether it has…
what is a unhealthy request? is searching for a user which was _not found_ by the server unhealthy? was the request successful? thats where different opinions exist.
Not weird at all if people don't strictly follow a standard. The world of programming, just like the real world, has a lot of misguided doctrines that looked really good on paper, but not on application. For example: "_links": { .... "cancel": { "href": "/orders/123/cancel", "method": "POST" } } Why "POST"? And what POST do you send? A bare POST with no data, or with parameters in it's body? What if you also want to…
Now you have a noun and some of confusion goes away regarding GET and DELETE etc