3 ms·

I'm not sure quite where you're going. You agree that having a client construct its own URLs from IDs is brittle. But then you propose an API to turn photo IDs

I'm not sure quite where you're going. You agree that having a client construct its own URLs from IDs is brittle. But then you propose an API to turn photo IDs into URLs—but that service itself lives at a particular URL, and is equally subject to change! Can you explain a bit more? I'm just surprised because returning URLs (not IDs) is a fundamental idea of proper REST.

Jare 15y ago
If the API entry point is subject to change then the very ability to access the service is in trouble, isn't it? In particular, my doubts about IDs vs URLs is the ability to store those pieces of data in the client (or intermediate caches) - if the service URLs or namespaces change, the client-side URLs become useless even after the client updates the service entry point. With IDs, that information would still be usable. I'm absolutely no expert on this so I'm probably in the "HTTP API, not REST API" side of the problem.
- newhouseb 15y ago
  Migrating anything will always be hard, sometimes services even migrate IDs (to something that is easier to shard intelligently against). As others mentioned you could either put redirects everywhere, but most services just version their REST APIs and then write glue to tie old interfaces to newer data models, see for example Twitter, Amazon AWS, and Instagram. One other semantic nitpick is that a URL is a subset of URI, which stands for Universal Resource Identifier, so in some sense you could make a philosophical argument that URI and IDs are/should be the same thing. If you were really crazy you could store URLs in your DB (obviously not a good idea for many other reasons).
- nileshtrivedi 15y ago
  Good point. I think the best way to handle URL changes is to use HTTP status 301 (permanently moved) for the old URLs. This can be applied consistently to APIs and webpages. This allows discoverable resources as well as re-discoverable URLs.
  - FuzzyDunlop 15y ago
    This is how a good API would handle the change. Deprecate the first URL, do a redirect to the new one for a period of time, then remove the original endpoints. Same concept as deprecating code. You don't wipe it out straight away because you have no idea what else might rely on it or how fast they are to react (within reason). As for the arguments about not using HTTP request methods - they're standard, and are implemented uniformly everywhere (for the best part). Your API isn't standard, but if all APIs use HTTP and its request methods correctly, you only need to learn the general HTTP spec to generally understand all APIs. Resources and URL structure afterwards is a matter of opinion. What may seem RESTful to me might not be to someone else.
- deleted 15y ago
  [deleted]
- masklinn 15y ago
  > In particular, my doubts about IDs vs URLs is the ability to store those pieces of data in the client (or intermediate caches) - if the service URLs or namespaces change, the client-side URLs become useless even after the client updates the service entry point. Which is OK, because the client can re-traverse the service to get back to those resources which are now invalid.

Jare 15y ago

If the API entry point is subject to change then the very ability to access the service is in trouble, isn't it? In particular, my doubts about IDs vs URLs is the ability to store those pieces of data in the client (or intermediate caches) - if the service URLs or namespaces change, the client-side URLs become useless even after the client updates the service entry point. With IDs, that information would still be usable. I'm absolutely no expert on this so I'm probably in the "HTTP API, not REST API" side of the problem.

newhouseb 15y ago
Migrating anything will always be hard, sometimes services even migrate IDs (to something that is easier to shard intelligently against). As others mentioned you could either put redirects everywhere, but most services just version their REST APIs and then write glue to tie old interfaces to newer data models, see for example Twitter, Amazon AWS, and Instagram. One other semantic nitpick is that a URL is a subset of URI, which stands for Universal Resource Identifier, so in some sense you could make a philosophical argument that URI and IDs are/should be the same thing. If you were really crazy you could store URLs in your DB (obviously not a good idea for many other reasons).
nileshtrivedi 15y ago
Good point. I think the best way to handle URL changes is to use HTTP status 301 (permanently moved) for the old URLs. This can be applied consistently to APIs and webpages. This allows discoverable resources as well as re-discoverable URLs.
- FuzzyDunlop 15y ago
  This is how a good API would handle the change. Deprecate the first URL, do a redirect to the new one for a period of time, then remove the original endpoints. Same concept as deprecating code. You don't wipe it out straight away because you have no idea what else might rely on it or how fast they are to react (within reason). As for the arguments about not using HTTP request methods - they're standard, and are implemented uniformly everywhere (for the best part). Your API isn't standard, but if all APIs use HTTP and its request methods correctly, you only need to learn the general HTTP spec to generally understand all APIs. Resources and URL structure afterwards is a matter of opinion. What may seem RESTful to me might not be to someone else.
deleted 15y ago
[deleted]
masklinn 15y ago
> In particular, my doubts about IDs vs URLs is the ability to store those pieces of data in the client (or intermediate caches) - if the service URLs or namespaces change, the client-side URLs become useless even after the client updates the service entry point. Which is OK, because the client can re-traverse the service to get back to those resources which are now invalid.