Hacker News new | past | comments | ask | show | jobs | submit login

Don't put your API on the same Domain as your website. Use api.company.com or a dedicated domain instead of company.com/api.



Or you could learn how to build REST-ful web interfaces correctly, in which case the problem goes away.

The only #SeparationOfConcerns that actually matters is:

1. Verbs describe actions upon resources (e.g. add, read, delete)

2. URIs identify individual resources you may wish to act upon

3. Content Types (and content negotiation) determine how a particular resource’s information will be encoded for transfer between client and server.

For instance, if a client has the following URI that points to a “person” resource:

    example.org/persons/12345
and the public documentation states that a person’s information can be represented in any of these formats:

- "text/html" (a standard human-readable webpage) - "application/org.example.person+json" (JSON-encoded machine-readable data) - "application/org.example.person+xml" (XML-encoded machine-readable data)

then the client can GET the resource’s data in one of three different formats, according to preference and/or need; e.g. standard web browser, custom smartphone app, Traditional Enterprise Application.


Interesting. What's the rationale?


It’s the separation of concerns best practice extended to domain names. To not have to think to path collisions if the website and the API are in the hands of different teams is a plus. As well, in this case, it’s a lot better to avoid the root domain which is less flexible then a subdomain. For instance, you can’t have a CNAME behind a root domain


Flexibility. A CNAME is easier than a reverse proxy.

Security. Don't share cookies with your site.


What if sharing cookies with your site is the intended behavior, e.g. for API's that you're calling directly from your frontend?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: