Hacker News Reader

The presentation is explicitly about REST, not about pragmatic dead simple solutions.

It even quotes Roy saying "Many of the constraints are directly opposed to short-term efficiency" and that most developers don't care about goals of rest.

I think points you're making are fine, but they're acknowledged in the presentation, so your rant is unnecessary.

I think the author did a good job presenting actual (you can say academic) REST, rather than a more popular and simpler to create "JSON-over-HTTP database" pattern (which is fine, but shouldn't technically be called "RESTful").

Point taken and I read the quote. But this was also quite adamant that if you didn't do it certain ways it was no longer REST. I think that is a bad way to present simplifying web services in REST and harmful. REST going mainstream was great simply to move away from all POST based SOAPY services.

Do you really believe if you don't use Accept headers as the only means of version that you aren't REST? Is REST a pattern you can follow only to the letter of Roy Fielding's dissertation? If so there might not be ANY REST web services out in the real market that are big. Everyone is just doing RESTish or RESTy instead of certified RESTful.

Also I believe HN is a place where we can discuss articles and pragmatic opinions about it, I don't assume everyone just agrees that this presentation was the one and only way to do REST like the author was stating. I stated my opinion to that. If this is the only way to do REST, simple services then the whole web isn't doing it yet.

This turned out like a rag on REST which it is not. It is a rag on over complicating and ivory tower architecture. REST should be about simplifying web services for consumers as well. When you get to implementing your RESTful service to support all clients, even with the current marke,t you will find it doesn't fit everywhere.

A service should be liberal in what it accepts and conservative in what it sends. The market deems when it is necessary to tighten the standards, right now his interpretation of it is too narrow.

We need a new standard called SIMPLE: RESTish/RPC, HTTP based, simple messaging (JSON/YAML), urls can be abstractions (in fact it is better to hide your models in most cases except for an admin scaffold), consumer aspect based routing (login, signup, myinfo) all the way from front end to service abstraction. Accept and formats can be in headers first and fall back to url based. Kinda like how systems like twitter, facbeook, 37 signals, etc do.

I suppose that boils down to prescriptivism vs descriptivism debate. I'm a prescriptivist in that case: there's Roy's thesis that defines what he meant by REST, and if an API (no matter how useful and successful) doesn't fit that description, it should be called something else.

I agree we need a good word for those HTTP-but-not-quite-REST APIs. I simply call them "HTTP APIs", but maybe SIMPLE, NoRPC or REST 2.0 will take off ;)

We recently finished a project that both consumed .NET WebServices (SOAP), produced Java WebServices (SOAP), and use REST-based library to provide a communication channel between 2 components.

Generating Java WebService client given .NET XSD/WSDL was a 5 minutes job. Ditto for the other way around: generating an XSD/WSDL from Java to be consumed by other parties was a 5 minute task (how the other party consumed it not of our concern).

OTOH, coming up with a good RESTful interface is proven to be very challenging. Some people coded up their REST interface to be like "/some/url/getInvoice", while others coded up their REST interface to follow Rails a bit more given their background. But sometime this second group that follows Rails convention were wondering how to implement the right REST interface for certain use-cases such as updating a boolean that is part of another bigger domain model object:

- What is the URL will look like?

- What kind of operation?

- What is the parameter?

- What is the return value?

You say you "generated" the clients. What happens when you need to change your services in a way that changes the WSDL? If your types or parameters change, your clients won't work anymore unless they re-read the WSDL. With Java and .NET, that generally requires recompiling the clients and redistributing them.

That's what Roy's talking about when he says REST is about designing on a long term scale. A client that uses a RESTful API should be parsing and navigating the representations dynamically, which allows them to handle changes in the representation gracefully. The clients can never handle semantic changes to the API, but they can handle structural changes.

What do I mean by that? If you provide links for paging, and the link for the next page uses rel="next", that's the semantic meaning for the link. Your client has to hardcode the knowledge that it needs to find the link with rel="next" in order to go to the next page. But, it doesn't matter where that link may appear in the page, or what the url for that link happens to be. These are both structural details that can change over time without breaking your client.

In reality, how achiveable/practical the scenarios you just explained regarding REST for both server and client side?

Your example also seems to be optimized for REST.

I am not suggesting that SOAP is much better.

It depends. JSON is very fragile.

You lose a tweet or two here or there, not a big issue. JSON will do it just fine.

Your bank on the other hand will prefer XML that can be validated with XSD and you don't lose your car payment. Or your salary deposit.

It's not academic, it's a matter of use case.

The example was largely web apis used for general consumption not private apis.

But yes, in terms of financial/gov't there can be other requirements. Lots of those systems are more enterprisy and may need that. However the same things can be done no matter the format, it still happens in EDI for instance over EDIHTTP/AS2 for POs and Invoices to Wal-mart everyday, it is not locked to XML and validated schemas only. JSON can be used there as well such as stripe.com does. The messaging is independent from a solid system really, I am just talking what is easier for large web consumption.

Can't see why you're being downvoted here. I think it's a reptilian defensive response from the REST academics.

I expected it, and yes it is because I touched on a belief system. People usually downvote without response when that happens.

I am big on REST I will reiterate, I included it in my own thesis in 2006 and the reason why I like it so much is it does make services more simple. I have been pusing it, JSON and simple apis since SOAP made my life hell (but was a needed notch to get away from proprietary formats and opening up data). Engineers jobs are to take complex things and make them simple to use for not just other engineers but non engineers without abstract thinking.

I just think repeating the historical mistakes of web services like SOAP can happen to JSON, REST and more if we don't check it with the current market and just keep it simple. I think REST is the way but you can have some flexibility for pragmatic business needs, lots of programmers cannot put business needs over ego at times. Don't tell people they aren't able to call it REST if it doesn't spit out ATOM representation and only use Accept headers.

Tell your business partners when your api doesn't work in a game engine because the http library didn't support headers that it isn't a true service and the client is unworthy of connecting. Or you could just use headers first then have other options/endpoints/abstracted urls to resources for non capable clients and still call it REST.

In the market today most big apis are RESTish RPC and that version will win because that is what is the most common service available today due to consumer/client demands. Granted it's not pretty.