A number of these points are not really a criticism of RESTful principles per se, but rather of typical REST over HTTP approaches. 1) Asynchronous APIs There's nothing about REST that says that operations must be performed synchronously. If a client updates a resource via a PATCH method and other services are notified of the update via a web hook or a message bus (possibly including the PATCH or the full resource), t…
You probably never heard about these, but these are the best for Binary protocols. If you know something else, or better please post. BEEP: http://www.aspl.es/vortex/ BSON: http://bsonspec.org/ (Binary Json)
REST API Alternatives
71–80 of 82 posts
Re: REST API Alternatives
#72Earlier quoted context omitted.
You probably never heard about these, but these are the best for Binary protocols. If you know something else, or better please post. BEEP: http://www.aspl.es/vortex/ BSON: http://bsonspec.org/ (Binary Json)
MessagePack: http://msgpack.org
My only complaint for msgpack early on was that they didn't differentiate binary from strings, and they didn't explicitly state the format for strings (like utf8) ... other than that, it's a pretty nice format, though I don't see it particularly better than those mentioned in the article, or bson and others mentioned in this discussion.
Re: REST API Alternatives
#73Earlier quoted context omitted.
Yeah. I've found a weird dichotomy in the general push to use "REST" for web APIs, but then certain aspects (true statelessness, for instance) are met with blank stares.
I get just as many blank stares when I'm presented with a client that is using SOAP (btw, I'd say 100% of SOAP shops are .NET shops at this point), but their SOAP message consists of a single-element datastructure, the single element containing an XML document which is the actual payload, and I try to say, "that's not really SOAP..."
I'll give this to .Net though, at least their wsdl files are complete enough to generate a .Net client from.. that's about all I will give it in that regard... I can't stand SOAP, it's too cumbersome, and even more verbose in transport.
Several times, in the past couple years, I've actually written internal translation services in node.js against public soap endpoints that I can more easily consume (usually in C#/.Net)
Also, I've seen a lot of SOAP written in Java as well... Though the couple of PHP "SOAP" services I've had to consume have been the worst by far.
Re: REST API Alternatives
#74A number of these points are not really a criticism of RESTful principles per se, but rather of typical REST over HTTP approaches. 1) Asynchronous APIs There's nothing about REST that says that operations must be performed synchronously. If a client updates a resource via a PATCH method and other services are notified of the update via a web hook or a message bus (possibly including the PATCH or the full resource), t…
You probably never heard about these, but these are the best for Binary protocols. If you know something else, or better please post. BEEP: http://www.aspl.es/vortex/ BSON: http://bsonspec.org/ (Binary Json)
Far simpler yet readable, there is the tried and tested bencode [0], or tnetstrings [1]. There are a little less efficient than pure-binary (especially regarding integers) and have less features, but are easier to read and write, even for a human, in my opinion.
[0] http://en.wikipedia.org/wiki/Bencode [1] http://tnetstrings.org/
Re: REST API Alternatives
#75REST is not losing its flair, this article's four points focus on things that have mostly nothing to do with the huge bread and butter of web services, which is getting businesses to talk to each other and share data between entirely unrelated applications. #1 does not apply because these are simple data sharing services and async has nothing to do with it; #2 does not apply because these services are not internal; #…
Yeah. I've found a weird dichotomy in the general push to use "REST" for web APIs, but then certain aspects (true statelessness, for instance) are met with blank stares.
True statelessness? Even if you disregard POST as "not true REST", the PUT and DELETE methods involve changing state. REST is an acronym for "representational STATE transfer", and is all about dealing with state in an simple and transparent way, not about avoiding it.
Re: REST API Alternatives
#76Earlier quoted context omitted.
> Better title: "Is using REST for everything a bad idea perhaps?" Turns out that yes, yes it is. For the vast majority of these uses, "REST" is a worthless and meaningless buzzword, so that's not a better title as the rise and fall of "REST" has nothing to do with it.
First of all, REST is pretty well-defined and is neither worthless, meaningless or a buzzword. Second of all, the rise and fall of REST doesn't have anything to do with the article either. The entire article can be summarized as "At first we wanted to design pure things, but then we realized we need optimizations as well. Is this the dead of purity in design?" It just makes no sense at all.
> First of all, REST is pretty well-defined and is neither worthless, meaningless or a buzzword
Reading comprehension, you definitely don't have it. I didn't say REST wasn't well-defined or was worthless, I said most of the uses of the acronym are as a worthless and meaningless buzzword, having very little to do with REST itself. That is a very different issue.
And since most of the uses of the "REST" acronym have little to do with actually RESTful system, the rise and fall of the buzzword has no relation with the rise and fall of RESTful system (which, objectively, have had very little rise in the first place)
Re: REST API Alternatives
#77Earlier quoted context omitted.
I wholeheartedly disagree with you -- you're ignoring hypermedia, an essential component in proper REST architecture. If one correctly leverages hypermedia, you may and most likely will have heterogenous responses and relations. Side-loading relevant relations is highly encouraged and is a core component of efficient API design. To your credit, I believe most of the information out there about REST and REST-like APIs…
I think you are both a bit of in nitpicking mode, right? I think the easy and normal and common path is to have canonical uri for ressources, and to serve agregated content for convenience or speed on other entry points, while adding to agregated content pointers to canonical uris. No?
We benefit from being pragmatic. thumbs up
Re: REST API Alternatives
#78Earlier quoted context omitted.
For lower volume "push" data, it would be nice if there were a convention in REST for how to request a subscription in which you provided the callback URL where the updates would be PUT. Not that this scales as well as message service "topics" (with multiple subscribers/listeners), but it's a start, and doesn't sound much worse than the load for point-to-point queues.
This is basically the description of webhooks
Cool, thanks.
Re: REST API Alternatives
#79A number of these points are not really a criticism of RESTful principles per se, but rather of typical REST over HTTP approaches. 1) Asynchronous APIs There's nothing about REST that says that operations must be performed synchronously. If a client updates a resource via a PATCH method and other services are notified of the update via a web hook or a message bus (possibly including the PATCH or the full resource), t…
You probably never heard about these, but these are the best for Binary protocols. If you know something else, or better please post. BEEP: http://www.aspl.es/vortex/ BSON: http://bsonspec.org/ (Binary Json)
wow, I'm amazed by your responses. Kudos to HN & I wish all of you "Happy New Year and a Merry Christmas" (⌐■_■)-♉
Re: REST API Alternatives
#80Earlier quoted context omitted.
You probably never heard about these, but these are the best for Binary protocols. If you know something else, or better please post. BEEP: http://www.aspl.es/vortex/ BSON: http://bsonspec.org/ (Binary Json)
Ah BEEP. I had a grad school project to create a domain specific modeling language that allowed you to diagram the steps for communication and between to systems using BEEP. You'd define the order of messages and the content of the messages the DSML would generate C code that implemented an API to do the communication you'd modeled. God how I hated grad school.
That sounds like an amazing experience you had. I can feel the pain! Had to write a custom compiler and backend and vm for it in school. And none of us had experience in C or Assembler. The compiler created a custom bytecode assembly that the VM had to run. Then another group made an FGPA and CPU that runs the code natively. Our prof's hobby was to write an OS for that board. But somehow we managed to do it. I still wow, when I look at the code. It makes me think.. how did I write that?