3 ms·

You might be right, as you've clearly thought about this more than I have. I have a couple of thoughts though. > A few years ago, before Rails made "REST" popu

by notJim 14y ago

You might be right, as you've clearly thought about this more than I have. I have a couple of thoughts though. > A few years ago, before Rails made "REST" popular, this exact same statement was made. "Nobody is going to want to learn about PUT and DELETE. They just want to do everything over POST." > This is an education problem. We're still in the early days of this stuff. The developers I was working with also had a lot of trouble with REST. I had to explain repeatedly what PUT, DELETE, GET and POST were (they weren't really familiar with HTTP at all), and that they weren't doing RPC calls. On the one hand, I feel REST is a simple and elegant concept and its not much to ask someone to understand, but on the other hand, when I build an API, I want it to be easy to use and accessible to developers of wide skillsets and levels of experience. To me, sacrificing some of my desire for elegance is worth it if it reduces the level of “education” required. > One thing that's nice about hypermedia is that you can lead clients to wherever you want them to go. You're free to change things at any time. Have a mobile app? Make less features, and make the request paths shorter. Have a desktop app? Make them longer, add more stuff. It's up to you. Nobody says that you have to complete N steps to do anything unless your server does. Either I'm not understanding you, or this seems totally backwards to the way APIs should work. You build an API so that users can do things with their data/your service that you haven't thought about, or cover edge cases that aren't interesting to you. I feel like my API should enable people to build the things they want, not limit and encumber them so that I can have my pretty hypermedia. In other words, I'm not interested in leading clients places. I'm interested in where they lead me.

steveklabnik 14y ago
> Either I'm not understanding you, or this seems totally backwards to the way APIs should work. The best hypermedia API that you know of is ATOM and ATOMpub. ATOM is data exchange, but it also describes how to edit entries and delete them. This allows many services to expose ATOM, many to consume it, and everything is peachy keen. The issue with 'just exposing data' is that you couple the business processes that your APIs do to organizations outside of your control. By exposing your processes (the 'state machine' of REST), you remove that coupling. You may want to see this talk: http://oredev.org/2012/sessions/designing-hypermedia-apis http://oredev.org/2012/sessions/designing-hypermedia-apis Of course, there are many APIs where 'just exposing data' makes sense. Hypermedia won't help you there, so don't use it. But if you want to build lasting, scalable, evolveable systems, then hypermedia is for you. If you just want to expose some data, then it's not.
politician 14y ago
On the client API issues, one of the criticisms of both REST and RPC APIs I've heard several times on HN is that consumers of APIs, regardless of the technology approach, fail to get it right (cf TLS). Moreover, the best remedy is to build and ship your own client libraries for as many platforms as possible.
BerislavLopac 14y ago
"The developers I was working with also had a lot of trouble with REST. I had to explain repeatedly what PUT, DELETE, GET and POST were (they weren't really familiar with HTTP at all), and that they weren't doing RPC calls." You should try using the SQL analogy instead of RPC, as this is much closer to what a "traditional" developer might expect. With REST, one is not doing a procedure call, but one is querying to create/retrieve/update/delete data. Of course, there might be some procedures behind it, but to a client it's just a data query (just like SQL has stored procedures of its own).
- steveklabnik 14y ago
  HTTP verbs do not map exactly to CRUD.
  - BerislavLopac 14y ago
    Of course they don't; but that's good enough for giving an intro to a "traditional" developer.

by notJim 14y ago

steveklabnik 14y ago

> Either I'm not understanding you, or this seems totally backwards to the way APIs should work. The best hypermedia API that you know of is ATOM and ATOMpub. ATOM is data exchange, but it also describes how to edit entries and delete them. This allows many services to expose ATOM, many to consume it, and everything is peachy keen. The issue with 'just exposing data' is that you couple the business processes that your APIs do to organizations outside of your control. By exposing your processes (the 'state machine' of REST), you remove that coupling. You may want to see this talk: http://oredev.org/2012/sessions/designing-hypermedia-apis http://oredev.org/2012/sessions/designing-hypermedia-apis Of course, there are many APIs where 'just exposing data' makes sense. Hypermedia won't help you there, so don't use it. But if you want to build lasting, scalable, evolveable systems, then hypermedia is for you. If you just want to expose some data, then it's not.

politician 14y ago

On the client API issues, one of the criticisms of both REST and RPC APIs I've heard several times on HN is that consumers of APIs, regardless of the technology approach, fail to get it right (cf TLS). Moreover, the best remedy is to build and ship your own client libraries for as many platforms as possible.

BerislavLopac 14y ago

"The developers I was working with also had a lot of trouble with REST. I had to explain repeatedly what PUT, DELETE, GET and POST were (they weren't really familiar with HTTP at all), and that they weren't doing RPC calls." You should try using the SQL analogy instead of RPC, as this is much closer to what a "traditional" developer might expect. With REST, one is not doing a procedure call, but one is querying to create/retrieve/update/delete data. Of course, there might be some procedures behind it, but to a client it's just a data query (just like SQL has stored procedures of its own).

steveklabnik 14y ago
HTTP verbs do not map exactly to CRUD.
- BerislavLopac 14y ago
  Of course they don't; but that's good enough for giving an intro to a "traditional" developer.