hateoas | 易学教程

Implementing/Overriding MongoRepository Keep HATEOAS Formatting

阅读更多关于 Implementing/Overriding MongoRepository Keep HATEOAS Formatting

问题 I have a simple MongoRepository I would like to modify to return the generated ObjectId on post(save()). public interface EmployeeRepository extends MongoRepository<Employee, String> { public void delete(Employee employee); public Employee save(Employee employee); public Employee findOne(String id); public List<Employee> findAll(); public Employee findByName(String principal); } I have explored ways to generate the id client side and pass it in the post BUT I really want Spring to handle this

RESt api: identification of resource and content varying based on authentication

阅读更多关于 RESt api: identification of resource and content varying based on authentication

问题 I'm designing an API following the HATEOAS / RESt principles. Yet I'm not sure about this basic point: identification of resource. Suppose this url: /images which exposes all the images uploaded by an user (to this user). Suppose I use an oauth access token for the authentication purpose, the content of /images will vary based on the Authorization header. Does this break the identification of resource concept ? 回答1: No. A resource does not have to be static to be restful. Imagine a webservice

Why is the HTTP location header only set for POST requests/201 (Created) responses?

阅读更多关于 Why is the HTTP location header only set for POST requests/201 (Created) responses?

问题 Ignoring 3xx responses for a moment, I wonder why the HTTP location header is only used in conjunction with POST requests/201 (Created) responses. From the RFC 2616 spec: For 201 (Created) responses, the Location is that of the new resource which was created by the request. This is a widely supported behavior, but why shouldn't it be used with other HTTP methods? Take the JSON API spec as an example: It defines a self referencing link for the current resource inside the JSON payload (not

spring rest data serialize to-one associations as related entity

阅读更多关于 spring rest data serialize to-one associations as related entity

How does one configure Spring Data Rest to serialize related entities directly ? I want it to look like this: note the "owner" link is to an "account" entity. { "name" : "customer", "_links" : { "self" : { "href" : "http://localhost:8081/api/v1/servers/1005" }, "owner" : { "href" : "http://localhost:8081/api/v1/account/100" } } } Currently (the default) has related entities (aka, associations) serialized indirectly. I DON'T want it to look like this: the "owner" link is via the self server entity. { "name" : "customer", "_links" : { "self" : { "href" : "http://localhost:8081/api/v1/servers

What is the importance of the self link in hypermedia APIs?

阅读更多关于 What is the importance of the self link in hypermedia APIs?

问题 All the articles and books I read on REST repeat the importance of adding "self" rel links to your hypermedia responses but they're all light on the reasons and use cases. Why should you add a self link and how is it useful? 回答1: The main reason is that clients (and even some servers) do not store the location of a representation with the representation. For example, if you wget http://.../foo.json , the representation will be saved to disk, but the URI at which it was fetched will not be. If

How to handle sensitive properties in a RESTful API (such as passwords, credit cards, etc)

阅读更多关于 How to handle sensitive properties in a RESTful API (such as passwords, credit cards, etc)

问题 Working on a REST framework that will support multiple hypermedia types and authentication. One thing I'm not really sure how to handle are sensitive values in the resources. For instance, if I were to include user management in the API, I would need a way to expose to the client that there was a field for the password, but not show the actual password hash. Same thing with a credit card. If I don't, it would violate the hypermedia constraint as knowledge of the fields would become out of

RESt api: identification of resource and content varying based on authentication

阅读更多关于 RESt api: identification of resource and content varying based on authentication

I'm designing an API following the HATEOAS / RESt principles. Yet I'm not sure about this basic point: identification of resource. Suppose this url: /images which exposes all the images uploaded by an user (to this user). Suppose I use an oauth access token for the authentication purpose, the content of /images will vary based on the Authorization header. Does this break the identification of resource concept ? No. A resource does not have to be static to be restful. Imagine a webservice that provides time-of-day: Http://www.myservice.com/current-time/ Nothing in the rest playbook would demand

Why most API paginations do not rely on HTTP Range header?

阅读更多关于 Why most API paginations do not rely on HTTP Range header?

问题 I've searched a lot but I can't find a good answer to this question. Being a HATEOAS aficionado, I would think that this header fit perfectly: Range: item=1-20/100 In the HTTP spec, I don't understand some "contradictions": The range unit can accept "other-range-unit"... range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token ... yet the spec is later explicit: The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges

Why is the HTTP location header only set for POST requests/201 (Created) responses?

阅读更多关于 Why is the HTTP location header only set for POST requests/201 (Created) responses?

Ignoring 3xx responses for a moment, I wonder why the HTTP location header is only used in conjunction with POST requests/201 (Created) responses. From the RFC 2616 spec : For 201 (Created) responses, the Location is that of the new resource which was created by the request. This is a widely supported behavior, but why shouldn't it be used with other HTTP methods? Take the JSON API spec as an example: It defines a self referencing link for the current resource inside the JSON payload ( not uncommon for RESTful APIs ). This link is included in every payload. The spec says that you MUST include

Link to another resource in a REST API: by its ID, or by its URL?

阅读更多关于 Link to another resource in a REST API: by its ID, or by its URL?

I am creating some APIs using apiary , so the language used is JSON. Let's assume I need to represent this resource: { "id" : 9, "name" : "test", "customer_id" : 12, "user_id" : 1, "store_id" : 3, "notes" : "Lorem ipsum example long text" } Is it correct to refer to other resources by their IDs ( 12 , 1 , 3 ), or I should specify the URL of these resources (i.e. /customers/12 , /users/1 , /stores/3 )? I am not using HATEOAS and I am a bit confused. stakx supports GoFundMonica DO include absolute entity URIs in your responses (such as /customers/12 or even http://www.example.com/customers/12 ).