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

REST API Alternatives

blog.programmableweb.com

Post reply on HN
Print view View original

41–50 of 82 posts

Re: REST API Alternatives

#41

Post by memracom »

Async is an important category that deserves better coverage. Fundamentally, REST and the alternatives (SOAP, etc.) are all RPC protocols. They may make use of the RPC nature of HTTP or maybe like XML-RPC they shove another RPC layer on top. A remote procedure call sounds like the simplest component of a remote api, but it is not. In RPC you make a request and wait for a reply.

But with async, you send a message and that is it. This can be implemented on top of HTTP RPC such as with Websockets, but the HTTP layer is unnecessary. Messaging using the AMQP protocol is a nice alternative. You can open a socket and hold it open for sending and receiving messages. When you send a message, it can be received by an MQ broker like RabbitMQ for guaranteed delivery to whatever internal service(s) need to process it. And when some kind of result needs to be sent back to the message originator, the socket is open and ready to receive it. For those things where the app needs RPC, it is simple to send a message and wait for a reply message. But when all you need is a notification going out, or coming in, that works too.

While MQTT and ZeroMQ and others could be used, it would be nicer if the Internet standardized on AMQP at a known port (just like HTTP) and even included the use of an MQ broker with all the optional services (topic queues, persistence, guaranteed delivery) that can be provided.

Re: REST API Alternatives

#42

Post by Roboprog »

mmerickel wrote: post #32
leeoniya wrote: post #17

the place where REST over HTTP fails badly IMO is batch operations and deep operations. when creating multiple entities at once, you cannot get back multiple location headers. and even if you could get back several headers, you have to re-request each of them via http to get their contents. it obligates you to be needlessly chatty. deep ops on multiple objects complicate things even further. i feel like once you get…

Yes, totally. It is completely lacking any mechanism that allows collection-level operations. If you want to create a bunch of resources you have to abandon the supported headers and return a list of ETags in the body, removing any niceties the client would've given you for standard "REST" support. Same for the Content-Location that you mentioned.

In practice, I don't think that stops people from making REST APIs that PUT/POST lists of sub-documents that each have an embedded ID.

Re: REST API Alternatives

#43

Post by StavrosK »

masklinn wrote: post #28
StavrosK wrote: post #8

Answer: This isn't even applicable. REST is still a good tool that applies to many jobs, use it where it makes sense, don't use it where it doesn't. Better title: "Is using REST for everything a bad idea perhaps?" Turns out that yes, yes it is.

> 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.

Re: REST API Alternatives

#44

Post by Roboprog »

KaiserPro wrote: post #13

All these are limited when you take a step back. The concept of poking about with HTTP to try and treat it vaguely like a TCP style transport protocol is rather silly. If you think about how "wordy" HTTP is, along with the standard RESTful verbs, you'll start to think "hmmm, perhaps this isn't the best way." Websockets and if you must a bit of JSON (binary if done properly is lower latency and much more efficient) sh…

Depends: which is more precious: network bandwidth, or my development time.

High volume: custom-binary wins, just like you said. Low volume: REST/text wins.

There's something to be said for being able to try out your API in a web browser in 2 minutes. Compression also goes a way in reducing the volume of text, though not the latency of follow up queries that are too finely granular.

Small, sharp, tools swapping text is very unixy. Even if sometimes the response is a binary document :-)

Re: REST API Alternatives

#45

Post by X4 »

pcl wrote: post #33

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)

Re: REST API Alternatives

#46

Post by Roboprog »

static_typed wrote: post #3

RESTful services still work in those situations where they are correctly applied. Maybe what has happened is some of the less mature and more shrill developers have stepped back from their war on any Web service that doesn't fit their dogmatic rest-tard view of the world. There are plenty of valid XML-RPC based services that continue to run well despite the whining that someone somewhere did not yet have a ruby gem t…

Simple XML-RPC interfaces can be OK, and they often have real documentation available, since they are not assumed to be magic, and that documentation will be needed. (we use several of these from a few vendors at work, they were not problematic to set up)

I've experienced a lot of pain trying to get working clients generated and configured from some magic WSDL (SOAP interface definition file), though. For a supposedly self describing standard, each time I have had to write a client, it was very much an "interesting" adventure.

My gut tells me there are many "Web Services" consultants who do not like REST because it simplifies things to the point where they are out of a job :-)

Re: REST API Alternatives

#47

Post by why-el »

alayne wrote: post #39
bryan_rasmussen wrote: post #25

I'm having trouble understanding the continual claiming that REST is not asynchronous - which I guess means that REST is synchronous. Saying it once would be a typo, but several times and I start to feel there is a distinct difference of opinion between myself and the author as to what constitutes a Restful architecture.

A typical RESTful API: PUT new data to resource x/y/z An asynchronous non RESTful API: POST job information for resource x/y/z GET status of job for resource x/y/z until status is complete. GET results of job for resource x/y/z

I think you left the realm of REST and reached out to the application level in order to make an non-existing case.

Your second example is only asynchronous in so far as you are oblivious to the completion of of the request, but that hardly makes it non-Restful. To me both of your examples are REST by definition.

Re: REST API Alternatives

#48

Post by pcl »

nmcfarl wrote: post #40
pcl wrote: post #33

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…

I'm fairly certain that when they describe an #2) Orchestration / Experience APIs they mean queries that return heterogeneous data, that one endpoint could retrieve the results of doing many queries, with many data types ie: GET /dashboard.json, retrieving all the resources used to assemble your dashboard page. This is very much different than the normal REST philosophy of returning only homogeneous results. Much mor…

the normal REST philosophy of returning only homogeneous results

Is that a thing? If 'GET /dashboard.json' obeyed the caching semantics of the resources it pulled together to present, and didn't have any surprising side effects, I'd still call that RESTful, even if it returned a rich graph of interesting data.

Re: REST API Alternatives

#49

Post by Roboprog »

memracom wrote: post #41

Async is an important category that deserves better coverage. Fundamentally, REST and the alternatives (SOAP, etc.) are all RPC protocols. They may make use of the RPC nature of HTTP or maybe like XML-RPC they shove another RPC layer on top. A remote procedure call sounds like the simplest component of a remote api, but it is not. In RPC you make a request and wait for a reply. But with async, you send a message and…

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.

Re: REST API Alternatives

#50

Post by tseabrooks »

X4 wrote: post #45
pcl wrote: post #33

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)

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.

Post reply on HN