Designing a Pragmatic RESTful API • Hacker News Board

Re: Designing a Pragmatic RESTful API

#11

Post by TylerE » Tue, Jun 04, 2013, 2:35 PM UTC

gizzlon wrote: post #9

shaydoc wrote: post #8

Earlier quoted context omitted.

You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key. When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext

Doesn't this open you up to replay attacks though? Since you can't store that a token was already used..

Sure you can. Just include a timestamp, and expire the token, at, say, time + 90 seconds, or whatever makes sense for the application.

Re: Designing a Pragmatic RESTful API

#12

Post by sltkr » Tue, Jun 04, 2013, 2:36 PM UTC

Kiro wrote: post #3

"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.

How is that fundamentally different from storing sessions in a database (which is common to be able to scale horizontally)?

Whether or not that is a lot of overhead depends also on how much work you were going to do to process the rest of the request. If your API allows sorting and filtering of a large data set, like the article suggests, then the authentication overhead is probably relatively small.

Re: Designing a Pragmatic RESTful API

#13

Post by shaydoc » Tue, Jun 04, 2013, 2:39 PM UTC

gizzlon wrote: post #9

shaydoc wrote: post #8

Earlier quoted context omitted.

You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key. When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext

Doesn't this open you up to replay attacks though? Since you can't store that a token was already used..

I failed to say that your token context should have a "time based expiration", in that a new token is reissued periodically as defined by you and your needs. I would refer to the ASP.NET Forms Auth mechanism with its sliding expiration.

Re: Designing a Pragmatic RESTful API

#14

Post by MostAwesomeDude » Tue, Jun 04, 2013, 2:39 PM UTC

Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.

Re: Designing a Pragmatic RESTful API

#15

Post by arethuza » Tue, Jun 04, 2013, 2:47 PM UTC

MostAwesomeDude wrote: post #14

Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.

I did think that the criticism of XML for being hard to parse was a bit odd. Although I generally prefer JSON for simpler stuff XML is pretty easy to parse and sift through with XPath.

Re: Designing a Pragmatic RESTful API

#16

Post by general_failure » Tue, Jun 04, 2013, 2:53 PM UTC

Kiro wrote: post #3

"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.

Use an expiring token like mechanism.

The API user first gets a token using credentials. Future requests use the token for authentication.

A new token will be required periodically.

Re: Designing a Pragmatic RESTful API

#17

Post by _pmf_ » Tue, Jun 04, 2013, 2:54 PM UTC

arethuza wrote: post #15

MostAwesomeDude wrote: post #14

Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.

I did think that the criticism of XML for being hard to parse was a bit odd. Although I generally prefer JSON for simpler stuff XML is pretty easy to parse and sift through with XPath.

It has to do with the awful XML generated by automatic tooling (SOAP by WCF and JEE).

Hand-generated XML can be just as nice as using hand-generated JSON, and on the other hand automatic domain-model-to-JSON mapping can be as ugly as any XML monstrosity.

Re: Designing a Pragmatic RESTful API

#18

Post by peterwwillis » Tue, Jun 04, 2013, 2:55 PM UTC

This is a well-written and informative article, kudos.

That said, it reminds me how fucking overcomplicated REST HTTP API is for 99% of uses. As an API user, all I want is to call a function on a server, pass it some arguments and get a result. I want it to be dead simple, and REST is probably the opposite of that.

Finally, it also occurs to me that most API calls may call one function which returns lots of data that I don't need. Specifying the data types and field names I want in the query would simplify parsing and potentially reduce bandwidth use (if you've ever seen an API call that returns a user's profile when all you wanted was their last login timestamp, you know what I mean). edit Whoops, didn't see he mentioned the field limiter... why don't more people do that?

Re: Designing a Pragmatic RESTful API

#19

Post by peterwwillis » Tue, Jun 04, 2013, 2:57 PM UTC

_pmf_ wrote: post #17

arethuza wrote: post #15

Earlier quoted context omitted.

I did think that the criticism of XML for being hard to parse was a bit odd. Although I generally prefer JSON for simpler stuff XML is pretty easy to parse and sift through with XPath.

It has to do with the awful XML generated by automatic tooling (SOAP by WCF and JEE). Hand-generated XML can be just as nice as using hand-generated JSON, and on the other hand automatic domain-model-to-JSON mapping can be as ugly as any XML monstrosity.

Though for the same dataset, XML will be slower to parse. For performance's sake use JSON.

Re: Designing a Pragmatic RESTful API

#20

Post by arethuza » Tue, Jun 04, 2013, 3:02 PM UTC

peterwwillis wrote: post #19

_pmf_ wrote: post #17

Earlier quoted context omitted.

It has to do with the awful XML generated by automatic tooling (SOAP by WCF and JEE). Hand-generated XML can be just as nice as using hand-generated JSON, and on the other hand automatic domain-model-to-JSON mapping can be as ugly as any XML monstrosity.

Though for the same dataset, XML will be slower to parse. For performance's sake use JSON.

I suspect that depends a lot on what platforms are used at the client and server.