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

31–40 of 82 posts

Re: REST API Alternatives

#31

Post by masklinn »

skyraider wrote: post #24
tim333 wrote: post #21

Earlier quoted context omitted.

I was puzzled briefly as to what JavaScript was doing there but thinking about it I've been doing some stuff with google maps and the API for that is mostly done with JavaScript objects.

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.

Re: REST API Alternatives

#32

Post by mmerickel »

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.

Re: REST API Alternatives

#33

Post by pcl »

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), the system is still following a RESTful design.

2) Orchestration / Experience APIs

A RESTful API does not need to require a separate GET for every individual resource. There's nothing wrong with implementing bulk queries that return variable projections of the server state tuned to the need of particular use cases.

Bulk modifications are trickier, especially when atomicity comes into play. But if atomicity is not a concern, then this is more of a transport problem, not a semantic one.

4) Binary protocols

Plenty of RESTful APIs (e.g., Twitter[1]) provide data in a number of payload formats. Choice of wire format is unrelated to whether or not the semantics of the API are RESTful.

[1] https://dev.twitter.com/docs/things-every-developer-should-k...

Re: REST API Alternatives

#34

Post by Corrado »

Its an OK article but I was really expecting to see some alternatives. I'm truly interested in something that compete with REST but was left wanting by the article.

Re: REST API Alternatives

#35

Post by DougWebb »

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…

For sending and retrieving multiple entities, you can use Multipart messages. The HTTP Location header would be a url for re-retrieving the multipart message, which is a representation of the resource which is the result of your request, and each of the entities within the message would need to have their own urls embedded within their representations.

I've used this approach for exactly the situation you're describing: batch operations that return multiple entities.

Re: REST API Alternatives

#36

Post by rch »

Corrado wrote: post #34

Its an OK article but I was really expecting to see some alternatives. I'm truly interested in something that compete with REST but was left wanting by the article.

I didn't think much of this article at all. I was expecting something possibly related to NetKernel or 9p, but was presented with... Thrift?

A more productive discussion might have started with Ext.Direct or Dojo RPC, but even those are just complementary channels, not alternatives.

Re: REST API Alternatives

#37

Post by tszming »

mrfusion wrote: post #30

Somewhat related question I've been meaning to ask. Why isn't xmlrpc more popular? At least in python it's incredibly easy to set up and to consume.

It depends what you mean by "popular", if you are talking about the number of XMLRPC service providers, then XMLRPC is far more popular as all wordpress installations have built in support for xmlrpc and are enabled by default.

Re: REST API Alternatives

#39

Post by alayne »

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

Re: REST API Alternatives

#40

Post by nmcfarl »

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 more RPC-ish.

Post reply on HN