Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

411–420 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#411

Post by agumonkey »

bornfreddy wrote: post #394
agumonkey wrote: post #386

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…

It's not that we like it, it's just that most other solutions are so complex and difficult to maintain that repetition is really not that bad a thing. I was however impressed with FastAPI, a python framework which brought together API implementation, data types and generating swagger specs in a very nice package. I still had to take care of integration tests by myself, but with pytest that's easy. So there are some s…

fastapi + sqlmodel does remove many layers that is true, but you still have other services requiring lots of boilerplate

Re: Most RESTful APIs aren't really RESTful

#412

Post by theamk »

yndoendo wrote: post #333
majkinetor wrote: post #327

Earlier quoted context omitted.

Amen. Particularly ISO8601.

Always thought that a standard like ISO8601 which always stores the date and time in UTC but appends the local time zone would beneficial.

I don't think I ever needed something like that... Since most cases don't need local time zone, why not keep two separate fields?

Re: Most RESTful APIs aren't really RESTful

#413

Post by agumonkey »

foobarian wrote: post #391
agumonkey wrote: post #386

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…

I've seen some systems with a lot of pieces where teams have attempted to avoid repetition and arranged to use a single source of schema truth to generate various other parts automatically, and it was generally more brittle and harder to maintain due to different parts of the pipeline owned by different teams, and operated on different schedules. Furthermore it became hard to onboard to these environments and figure…

I see, it's also reminiscent of the saying "microservices" are an organisational solution. It's just that I also see a lot of churn and friction due to incoherent versions and specs not being managed in sync now (some solutions exists are coming though)

Re: Most RESTful APIs aren't really RESTful

#414

Post by uzerfcwn »

mixedbit wrote: post #343
Balooga wrote: post #319

Earlier quoted context omitted.

> You describe how web pages work, web pages are intended for human interactions Exactly, yes! The first few sentences from Wikipedia... "REST (Representational State Transfer) is a software architectural style that was created to describe the design and guide the development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hyperme…

Most web apps today use APIs that return JSON and are called by JavaScript. Can you use REST for such services or does REST require a switch to HTML representation rendered by the server where each interaction returns new HTML page? How such HTML representation can even use PUT and DELETE verbs, as these are available only to JavaScript code? What If I design a system where API calls can be made both from the web and…

> Most web apps today use APIs that return JSON and are called by JavaScript. Can you use REST for such services

You kind of could, but it's a bad idea. A core tenet of the REST architecture is that it supports a network of independent servers that provide different services (i.e. webpages) and users can connect to any of them with a generic client (i.e. a web browser). If your mission is to build a specialized API for a specialized client app (a JS web app in your example), then using REST just adds complexity for no reason.

For example, you could define a new content-type application/restaurantmenu+json and build a JS client that renders the content-type like a restaurant's homepage. Then you could use your restaurant browser JS client to view any restaurant's menu in a pretty UI... except your own restaurant's server is the only one that delivers application/restaurantmenu+json, so your client is only usable on your own page and you did a whole lot of additional work for no reason.

> does REST require a switch to HTML representation ... How such HTML representation can even use PUT and DELETE verbs

Fielding's REST is really just an abstract idea about how to build networks of services. It doesn't require using HTTP(S) or HTML, but it so happens that the most significant example of REST (the WWW) is built on HTTPS and HTML.

As in the previous example, you could build a REST app that uses HTTP and application/restaurantmenu+json instead of HTML. This representation could direct the client to use PUT and DELETE verbs if you like, even though these aren't a thing in HTML.

Re: Most RESTful APIs aren't really RESTful

#415

Post by antonvs »

ehutch79 wrote: post #282
recursivedoubts wrote: post #255

Earlier quoted context omitted.

Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!

No. I was served HTML. not a json respoise that the browser discovered how to display.

The connection between the "H" in HTML and the "H" in HATEOAS might help you connect some dots.

Re: Most RESTful APIs aren't really RESTful

#416

Post by marcosdumay »

bokchoi wrote: post #331
marcosdumay wrote: post #259

Earlier quoted context omitted.

I really hate my conclusions here, but from a limited freedom point of view, if all of that is going to happen... > The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec So we should better start with a standard scaffolding for the replies so we can encode the errors and forget about status codes. So the only thing generating an error status is unhandled excepti…

The world would be lovely if we could have standard error, listing responses, and a common query syntax. I haven't done REST apis in a while, but I came across this recently for standardizing the error response: https://www.rfc-editor.org/rfc/rfc9457.html

I really like the idea of a type URL.

Re: Most RESTful APIs aren't really RESTful

#417

Post by Waterluvian »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

I describe mine as a JSON-Based Representational State SOAP API to other internal teams. When their eyes cross I get to work sifting through the contents of their pockets for linting errors and JIRA tickets.

Re: Most RESTful APIs aren't really RESTful

#418

Post by cyberax »

jerf wrote: post #376
PaulHoule wrote: post #371

Earlier quoted context omitted.

People get stuff done despite at all that.

I'd agree with your great-grandparent post... people get stuff done because of that. There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards that sloppyREST has casually dispatched (pun fully intended) in the real world. After some 30+ years of highly prescriptive RPC mechanisms, at some point it becomes time to stop waiting for those things to unseat…

> 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: https://web.archive.org/web/20040603094344/http://www.zeroc.... Their ICE suite was basically an RPC with a human-designed IDL and non-crazy bindings for C/C++/Java.

Then the situation got WORSE when SOAP came.

At this point, anything, literally anything, that didn't involve XML was greeted with enthusiasm.

Re: Most RESTful APIs aren't really RESTful

#419

Post by synergy20 »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

RESTful has gone far beyond the http world. It's the new RPC with JSON payload for whatever. I use it on embedded systems that has no database at all, POST/GET/PUT/DELETE etc are perfectly simple to map into WRITE|READ|Modify|Remove commands. As long as the API is documented, I don't really care about its http origins.

Re: Most RESTful APIs aren't really RESTful

#420

Post by ivan_gammel »

troupo wrote: post #401
ivan_gammel wrote: post #302

Earlier quoted context omitted.

It’s something else. List of available actions may include other resources, so you cannot express it with pure HTTP, you need a data model for that (HAL is one of possible solutions, but there are others)

With HATEOAS you're supposed to return the list of available actions with the representation of your state. Neo4j's old REST API was really good about that. See e.g. get node: https://neo4j.com/docs/rest-docs/current/#rest-api-get-node

That API doesn’t look like REST level 3 API. For example, there’s an endpoint to create a node. It is not referenced by root or anywhere else. GetNode endpoint does include some traversal links in response, but those links are part of domain model, not part of the protocol. HAL does offer a protocol by which you enhance your domain model with links with semantics and additional resources.
Post reply on HN