5 ms·

From a quick glance: - Doesn't use HTTP verbs (GET, PUT, POST, DELETE) to retrieve, modify, create and remove objects. - Doesn't use a restful url path to act

by poutine 15y ago

From a quick glance: - Doesn't use HTTP verbs (GET, PUT, POST, DELETE) to retrieve, modify, create and remove objects. - Doesn't use a restful url path to action on (ie. GET /users/#{user_id} to get a specific user by id, POST /users to create a new user). - Doesn't use HTTP codes to return results (ie. HTTP 200 for normal operations, 201 for created, 40x for error conditions).

masklinn 15y ago
> - Doesn't use a restful url path to action on (ie. GET /users/#{user_id} to get a specific user by id, POST /users to create a new user). That is specifically one thing which does not apply and is completely irrelevant. Good-looking URLs have nothing to do with REST. The rest, yes.
- poutine 15y ago
  That may be so, however he asked what else is wrong with this API. An ugly URL scheme is something wrong with an API in my opinion and lots of people agree (see Rails, etc).
  - masklinn 15y ago
    > That may be so, however he asked what else is wrong with this API. He asked it in the context of API restfullness, as is pretty clear from the second phrase.
    - Eduard 15y ago
      I thank you all for your great responses you have given so far. I meant my question in the restfulness way, but poutine adds best practice advises that I'm more than happy to also know about.
- SimHacker 15y ago
  Isn't it more "cache friendly" to use urls that address objects by path, instead of addressing them by query parameters? Like http://foo.com/rest/suite/foo/bar http://foo.com/rest/suite/foo/bar is more likely to be cached than http://foo.com/rest/suite?dir=foo&file=bar http://foo.com/rest/suite?dir=foo&file=bar or http://foo.com/rest/suite?file=bar&dir=foo http://foo.com/rest/suite?file=bar&dir=foo
  - masklinn 15y ago
    That is possible (for stupid caches anyway, on purely technical grounds there should be no difference), it also looks much better to developers/users and is much, much easier to map/dispatch in most frameworks. I was just talking about the restful part of the thing, your urls can look like this: http://example.org/?wubwub=9cec6c6faef8f7ccefe1bbf409368f1e3d0fa626 and still be part of a completely and perfectly restful service.

by poutine 15y ago

masklinn 15y ago

> - Doesn't use a restful url path to action on (ie. GET /users/#{user_id} to get a specific user by id, POST /users to create a new user). That is specifically one thing which does not apply and is completely irrelevant. Good-looking URLs have nothing to do with REST. The rest, yes.

poutine 15y ago
That may be so, however he asked what else is wrong with this API. An ugly URL scheme is something wrong with an API in my opinion and lots of people agree (see Rails, etc).
- masklinn 15y ago
  > That may be so, however he asked what else is wrong with this API. He asked it in the context of API restfullness, as is pretty clear from the second phrase.
  - Eduard 15y ago
    I thank you all for your great responses you have given so far. I meant my question in the restfulness way, but poutine adds best practice advises that I'm more than happy to also know about.
SimHacker 15y ago
Isn't it more "cache friendly" to use urls that address objects by path, instead of addressing them by query parameters? Like http://foo.com/rest/suite/foo/bar http://foo.com/rest/suite/foo/bar is more likely to be cached than http://foo.com/rest/suite?dir=foo&file=bar http://foo.com/rest/suite?dir=foo&file=bar or http://foo.com/rest/suite?file=bar&dir=foo http://foo.com/rest/suite?file=bar&dir=foo
- masklinn 15y ago
  That is possible (for stupid caches anyway, on purely technical grounds there should be no difference), it also looks much better to developers/users and is much, much easier to map/dispatch in most frameworks. I was just talking about the restful part of the thing, your urls can look like this: http://example.org/?wubwub=9cec6c6faef8f7ccefe1bbf409368f1e3d0fa626 and still be part of a completely and perfectly restful service.