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

61–70 of 82 posts

Re: REST API Alternatives

#61

Post by nmcfarl »

sjtgraham wrote: post #57
nmcfarl wrote: post #55

Earlier quoted context omitted.

Yeah - but what if it returned a collection of orders also retrievable from /orders/search?date=today and customers from /customers/search?lastorderdate=today&totallifteimevalue=greaterthan,100000 and support tickets from /support/tickets/search?state=open This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports.

> This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports. This is nothing to do with REST. Read the Wikipedia article for a crash course.

I have, I agree. However the common design patterns for REST APIs encourage canonical URIs for resources, and discourage the same resource being retrieved from multiple locations - which heterogenous collections inevitably lead to.

Perhaps I should have said discouraged in the common patterns for implementing REST and REST-like APIs.

Re: REST API Alternatives

#62

Post by habitue »

Roboprog wrote: post #49
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.

This is basically the description of webhooks

Re: REST API Alternatives

#63

Post by skyraider »

masklinn wrote: post #31
skyraider wrote: post #24

Earlier quoted context omitted.

Probably talking about JSON and similar formats like JSON API.

Which makes very little sense, since JSON is a content type it's mostly orthogonal to using REST, *RPC or whatever. You can do REST with JSON, XML, custom binary or ad-hoc textual payloads, and you can do RPC with exactly the same.

Sure. Another way to interpret "JavaScript" is that it means using one of the various data-binding frameworks. But who knows, I didn't write the article.

Re: REST API Alternatives

#64

Post by mahmoudimus »

nmcfarl wrote: post #61
sjtgraham wrote: post #57

Earlier quoted context omitted.

> This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports. This is nothing to do with REST. Read the Wikipedia article for a crash course.

I have, I agree. However the common design patterns for REST APIs encourage canonical URIs for resources, and discourage the same resource being retrieved from multiple locations - which heterogenous collections inevitably lead to. Perhaps I should have said discouraged in the common patterns for implementing REST and REST-like APIs.

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 discount how much work actually goes into building a proper REST API with hypermedia -- so we will always have half-baked design patterns that solve problems when doing REST incorrectly.

Re: REST API Alternatives

#65

Post by scott_w »

This article just demonstrates the author's total lack of understanding of REST.

Let's start with asynchronous API. You can easily POST a request, get a new URL back, the just poll it until you get a result (returning 202 in the meantime). The simplest article explaining it can be found here:

http://www.infoq.com/articles/webber-rest-workflow

It's not even that hard - almost every website that generates non-trivial reports does it somewhere. REST hides all the implementation details behind simple resources (URLs in the HTTP world).

Orchestation: Go look up SPARQL. Yes, the language itself isn't pretty, but it's proof that you can orchestrate some pretty complex reports if you like. As pcl notes, you can do it with simpler URLs too. It's all down to the web service.

For SDKs... they tend to be reserved for the nastier APIs (usually involving XML).

Binary protocols? Seriously? There are entire theses dedicated to the fact that HTTP was designed to deal with this stuff. Go read the documentation on HTTP Accept headers.

I'm not surprised there are badly designed HTTP interfaces out there; but criticising the architectural style itself based on your own lack of knowledge helps nobody.

Re: REST API Alternatives

#66

Post by TheZenPsycho »

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)

Might as well add protocol buffers to this list http://code.google.com/p/protobuf/

and OSC: http://opensoundcontrol.org

and ASN.1 http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

Re: REST API Alternatives

#67

Post by scott_w »

nmcfarl wrote: post #55
pcl wrote: post #48

Earlier quoted context omitted.

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.

Yeah - but what if it returned a collection of orders also retrievable from /orders/search?date=today and customers from /customers/search?lastorderdate=today&totallifteimevalue=greaterthan,100000 and support tickets from /support/tickets/search?state=open This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports.

Not really. Returning hetergeneous data is perfectly RESTful if that is what the endpoint describes. You might want to be more descriptive in the URL, however:

/dashboard?type=orders&type=customers&type=support

With either some documentation explaining the differences, or even the return value itself describing what's in e.g.

{"orders": {"date": "today", "data": [...]}, ... }

What you return depends entirely on the context of your web service. If people are telling you to always return a homogenous set of results then they're wrong. You know your application better than some random guy on the internet.

Re: REST API Alternatives

#68

Post by [deleted] »

nmcfarl wrote: post #55
pcl wrote: post #48

Earlier quoted context omitted.

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.

Yeah - but what if it returned a collection of orders also retrievable from /orders/search?date=today and customers from /customers/search?lastorderdate=today&totallifteimevalue=greaterthan,100000 and support tickets from /support/tickets/search?state=open This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports.

[deleted]

Re: REST API Alternatives

#69

Post by [deleted] »

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

[deleted]

Re: REST API Alternatives

#70

Post by gbog »

mahmoudimus wrote: post #64
nmcfarl wrote: post #61

Earlier quoted context omitted.

I have, I agree. However the common design patterns for REST APIs encourage canonical URIs for resources, and discourage the same resource being retrieved from multiple locations - which heterogenous collections inevitably lead to. Perhaps I should have said discouraged in the common patterns for implementing REST and REST-like APIs.

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?

Post reply on HN