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

Designing a Pragmatic RESTful API

vinaysahni.com

Post reply on HN
Print view View original

71–80 of 139 posts

Re: Designing a Pragmatic RESTful API

#71

Post by shaydoc »

gizzlon wrote: post #22
TylerE wrote: post #11

Earlier quoted context omitted.

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

I get that you can expire it, and that helps, but it's not the same as use-once. Of course, just using a timeout is probably fine in many cases, especially if it's used with SSL. But replay attacks are still possible since there's a windows where it can be re-used.

Replay attacks are always gonna be possible unless you use a one time token or signature, thems the break's..., unless you wish to get into the something you have and something you know model. How can you do a use once token making concurrent requests without a strong authentication mechanism client side such as issuing private keys to clients....and all the PKI admin overhead. I think its safe to say, that a restful api should be stateless, and bottlenecks such as session state are not necessary.

Re: Designing a Pragmatic RESTful API

#72

Post by diminoten »

buro9 wrote: post #70
T-hawk wrote: post #68

Earlier quoted context omitted.

While we're dispelling SSL myths, let me add the reminder that SSL does encrypt the URL and querystring and HTTP headers. It doesn't look like it in browsers because they still show the URL cleartext onscreen, but over the wire all of that is indeed inside the encryption envelope. Only the destination IP address isn't encrypted.

And whilst we're still here... SNI and SSL. Thanks to Internet Explorer, and the early versions of the stock browser on Android, you will need a unique IPv4 address for your SSL endpoint. You cannot safely serve multiple SSL sites on the same IP.✝ Basically: The hostname is also encrypted, so the SSL requests on some browsers require a unique IPv4 address. Your provider will give you one if you say the magic word "SS…

Huh, TIL. What was the reasoning behind this?

Re: Designing a Pragmatic RESTful API

#73

Post by icebraining »

dragonwriter wrote: post #69
icebraining wrote: post #65

Earlier quoted context omitted.

That's media types. I was referring to the strings used in content-type, the HTTP header. You obviously need to support some media type, otherwise how would you represent a resource? But you don't need to support the Content-Type header to have HATEOAS.

> That's media types. I was referring to content-type, the HTTP header. You obviously need to support some media type, otherwise how would you represent a resource? But you don't need to support the Content-Type header to have HATEOAS. If you are doing a REST architecture with a protocol other than HTTP, sure. But since the Content-Type header is the mechanism by which HTTP communicates media types, and since in-band…

  file document
  document: HTML document, UTF-8 Unicode text
You can distinguish between media types without using the Content-Type header or out-of-band communication. In fact, there's a (non-standard) header for preventing some browsers from replacing the Content-Type value with their own guess.

It's obviously useful, especially for distinguishing between similar media types (e.g. JSON document with different schemas), but not necessary for HATEOAS.

Re: Designing a Pragmatic RESTful API

#74

Post by buro9 »

diminoten wrote: post #72
buro9 wrote: post #70

Earlier quoted context omitted.

And whilst we're still here... SNI and SSL. Thanks to Internet Explorer, and the early versions of the stock browser on Android, you will need a unique IPv4 address for your SSL endpoint. You cannot safely serve multiple SSL sites on the same IP.✝ Basically: The hostname is also encrypted, so the SSL requests on some browsers require a unique IPv4 address. Your provider will give you one if you say the magic word "SS…

Huh, TIL. What was the reasoning behind this?

Who knows. I prefer to focus on what needs to be done to make things work.

Re: Designing a Pragmatic RESTful API

#75

Post by protonfish »

buro9 wrote: post #56

We've built a first version of an API that we have in testing at the moment, and it follows a lot of the things laid out in an ebook✝ and in the linked article. The epiphany we had was that whilst machines do access the API, the developer is always the customer and user. Everything we do should help the developer, and if we have to break rules to help them... then largely we should. I've built a couple of very pure R…

I don't think what the developers are asking for is inherently not RESTful, as long as there is already a strict REST implementation. Adding composite resources in addition to the decoupled ones seems like a intuitive way to improve the usability of the API and the performance of the application (so there aren't so many API calls for common procedures.)

Re: Designing a Pragmatic RESTful API

#76

Post by jfaucett »

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.

when he says "use JSON where possible XML only where you have to", I thought it was funny, like developers out there are just dying to use this verbose behemoth instead of its terser cousin json. But anyways, I agree with everything you're saying just wondering if there actually are any devs out there who just adore some sweet XML (seriously) ?

Re: Designing a Pragmatic RESTful API

#77

Post by h2s »

buro9 wrote: post #56

We've built a first version of an API that we have in testing at the moment, and it follows a lot of the things laid out in an ebook✝ and in the linked article. The epiphany we had was that whilst machines do access the API, the developer is always the customer and user. Everything we do should help the developer, and if we have to break rules to help them... then largely we should. I've built a couple of very pure R…

    The epiphany we had was that whilst machines do access
    the API, the developer is always the customer and user.
    Everything we do should help the developer, and if we
    have to break rules to help them... then largely we
    should.
Thank you, this articulates my disagreement with the idea of hashing all URLs so that client developers are forced to follow links returned by the API instead of generating their own URLs

http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-ha...

Re: Designing a Pragmatic RESTful API

#78

Post by veesahni »

diminoten wrote: post #72
buro9 wrote: post #70

Earlier quoted context omitted.

And whilst we're still here... SNI and SSL. Thanks to Internet Explorer, and the early versions of the stock browser on Android, you will need a unique IPv4 address for your SSL endpoint. You cannot safely serve multiple SSL sites on the same IP.✝ Basically: The hostname is also encrypted, so the SSL requests on some browsers require a unique IPv4 address. Your provider will give you one if you say the magic word "SS…

Huh, TIL. What was the reasoning behind this?

When client connects to server, first it does the SSL handshake. Then it sends HTTP headers.

As a result, SSL really has nothing to do with HTTP and could be used to wrap other protocols. Check out stunnel ( https://www.stunnel.org/index.html ) which can be used to arbitrarily encrypt communications for any TCP based protocol

Re: Designing a Pragmatic RESTful API

#79

Post by RyanMcGreal »

johns wrote: post #62
ExpiredLink wrote: post #45

Earlier quoted context omitted.

The obligatory "you're doing it wrong" comment following virtually all REST articles.

Once people stop calling it the wrong thing, the discussion can be about something else. I also hate this nitpicking, but it's clearly not going away so you're better off not inviting it by using the term incorrectly.

It's why I've come to prefer the term "RESTish". It probably still isn't enough to mollify hard-core purists but indicates that, e.g. the user knows versioning ought to be in the accept header rather than the URL, but also that hardly anyone either creating or using web APIs cares.

Re: Designing a Pragmatic RESTful API

#80

Post by brown9-2 »

protonfish wrote: post #21

I am not sure I follow his point about why HATEOAS is not practical, but I know that I have been able to make it work in my own REST APIs using content types. I only return JSON if the Accept header specifies "application/json". (Which is probably what you should be doing anyhow.) I usually also allow an HTML fragment response for the "text/html-fragment" Accept type. The default response type (or if "text/html" is e…

Does your JSON response at the root entry point to the API return something signifying what all possible operations are?

Does the JSON representation of a Employee object returned URLs as a part of the body for the resource addresses for any "child" objects?

I don't think it can be considered HATEOAS if the answer to either is no.

Post reply on HN