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

51–60 of 82 posts

Re: REST API Alternatives

#51

Post by ksrm »

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)

CBOR [0] is a proposed standard that seems much more efficient than BSON - check out the appendix [1].

[0] http://tools.ietf.org/html/rfc7049

[1] http://tools.ietf.org/html/rfc7049#appendix-E.6

Re: REST API Alternatives

#52

Post by bmelton »

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…

Regarding 2) that's a 'potAYto potAHto' scenario, I think. The way I've used them in the past are to address performance concerns from customers. We have the general RESTful webservices that cover all uses cases, in that every object has an endpoint, blah blah, and the design generally conforms to RESTful paradigms.

Beyond that though, customers often request changes, additions, optimizations, etc., and as they're paying us money, we try to be as accommodating as possible. In many cases, these endpoints are customer-specific, and violate the living daylights out of the RESTful design paradigm -- often exposing 'flattened' views for convenience.

To use the Github API for reference, to get the status of an issue, you have to query the issues for the repository, then the comments and events for the issue, and then the commit messages that are associated with the events.

An example of a non-RESTful paradigm is to simply JOIN the issue's comments and events and associate the relevant commit messages to the events so that they can all be captured in one call.

It isn't truly RESTful, but it's awfully damn convenient pertaining to customer overhead, and we still call it REST, and they don't bother correcting us.

Re: REST API Alternatives

#53

Post by zzzeek »

sopooneo wrote: post #26
zzzeek wrote: post #12

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

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

Re: REST API Alternatives

#54

Post by dustingetz »

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)

http://thrift.apache.org/

Re: REST API Alternatives

#55

Post by nmcfarl »

pcl wrote: post #48
nmcfarl wrote: post #40

Earlier quoted context omitted.

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.

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.

Re: REST API Alternatives

#56

Post by grncdr »

bmelton wrote: post #52
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…

Regarding 2) that's a 'potAYto potAHto' scenario, I think. The way I've used them in the past are to address performance concerns from customers. We have the general RESTful webservices that cover all uses cases, in that every object has an endpoint, blah blah, and the design generally conforms to RESTful paradigms. Beyond that though, customers often request changes, additions, optimizations, etc., and as they're pa…

An alternative approach that I've implemented in the past [0] (and found quite useful) is client-driven server-side inlining of linked resources.

What this means in practice is that the client specifies (usually with a query parameter) what related resources they are interested in, and the server can pre-fetch those resources and include them in the response.

Obviously there's some upfront development costs and your API needs to have a well-linked taxonomy of resources, but it allows the client to create these 'flattened views' on the fly with no further work on your part.

Edit: Just wanted to clarify that IMO this is a RESTful design because you are still using links to navigate your API resources, you're just writing a "smarter" server that can reduce the number of requests.

[0] https://github.com/BetSmartMedia/lazorse-nesting

edit: fixed link

Re: REST API Alternatives

#57

Post by sjtgraham »

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.

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

Re: REST API Alternatives

#58

Post by sjtgraham »

bmelton wrote: post #52
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…

Regarding 2) that's a 'potAYto potAHto' scenario, I think. The way I've used them in the past are to address performance concerns from customers. We have the general RESTful webservices that cover all uses cases, in that every object has an endpoint, blah blah, and the design generally conforms to RESTful paradigms. Beyond that though, customers often request changes, additions, optimizations, etc., and as they're pa…

> In many cases, these endpoints are customer-specific, and violate the living daylights out of the RESTful design paradigm -- often exposing 'flattened' views for convenience.

This doesn't violate REST. The WWW is the canonical RESTful system, i.e. A client enters the API (a website) via a common entry point (example.com), navigates using links, and manipulates state using a shared understanding of a common media type (HTML and HTML forms). Think about it, when you go to a web page do you expect it to be about strictly one thing, e.g. when viewing a blog post, do you expect it to click a link to navigate to each comment? No, that would be insane. Does that make it non-RESTful? No. It is perfectly reasonable for a resource to be composed of other addressable resources.

Re: REST API Alternatives

#59

Post by sjtgraham »

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)

MessagePack: http://msgpack.org

Re: REST API Alternatives

#60

Post by phamilton »

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

It's all just relative though. If the resource is the job itself, then you have CRUD over REST for the job resource. The queue processing the job is a RESTful consumer as well, updating the job with information about the resulting new resource.

That is all RESTful. Whether or not its useful is a different question.

Post reply on HN