RESTful API에서 객체 계층을 어떻게 처리해야합니까?

RESTful API에서 객체 계층을 어떻게 처리해야합니까?

---

저는 현재 기존 PHP 애플리케이션 용 API를 설계하고 있으며이를 위해 현명한 아키텍처 접근 방식으로 REST를 조사하고 있습니다.

핵심 개념을 합리적으로 이해하고 있다고 생각하지만 개체 계층 구조와 REST를 다룬 사람을 찾기 위해 고군분투하고 있습니다.

여기에 문제가 있습니다 ...

[애플리케이션] 비즈니스 오브젝트 계층에는 다음이 있습니다.

Users 
 L which have one-to-many Channel objects
 L which have one-to-many Member objects

애플리케이션 자체에서 지연로드 방식을 사용하여 필요에 따라 User 개체를 이러한 개체의 배열로 채 웁니다. 나는 OO 용어로 이것이 객체 집합이라고 믿지만, 다양한 명명 불일치를 보았고 정확한 명명 규칙에 대한 전쟁을 시작하는 데 관심이 없습니다.

지금은 응용 프로그램의 필요에 따라 채워지거나 채워지지 않을 수있는 느슨하게 결합 된 개체가 있다고 생각해보십시오.

REST 관점에서 나는 접근 방식이 무엇인지 확인하려고 노력하고 있습니다. 내 현재 생각은 다음과 같습니다 (당분간 GET 고려).

옵션 1-개체를 완전히 채 웁니다.

GET api.example.com/user/{user_id}

User 객체 (리소스)를 읽고 가능한 모든 Channel 및 Member 객체가 미리로드되고 인코딩 된 (JSON 또는 XML)과 함께 User 객체를 반환합니다.

장점 : 개체 수를 줄이고 개체 계층 구조를 탐색하지 않아도됩니다.
단점 : 개체를 완전히 채워야합니다 (비쌈).

옵션 2-기본 개체를 채우고 다른 개체 리소스에 대한 링크를 포함합니다.

GET api.example.com/user/{user_id}

사용자 개체 (자원)를 읽고 채워진 사용자 개체 사용자 데이터와 두 개의 목록을 반환합니다.

각 목록은 적절한 (하위) 리소스를 참조합니다.

api.example.com/channel/{channel_id}
api.example.com/member/{member_id}

나는 이것이 하이퍼 미디어의 의미에 가깝거나 정확히 같다고 생각합니다. 클라이언트는 원한다면 다른 리소스를 얻을 수 있습니다.

장점 : 클라이언트는 부하 직원을로드하도록 선택할 수 있습니다. 그렇지 않으면 REST 리소스로 개체를 더 잘 분리 할 수 ​​있습니다
. 단점 : 보조 리소스를 가져 오는 데 추가 이동이 필요합니다.

옵션 3-재귀 검색 사용

GET api.example.com/user/{user_id}

사용자 개체를 읽고 하위 개체 목록에 대한 링크를 포함합니다.

api.example.com/user/{user_id}/channels
api.example.com/user/{user_id}/members

/ channels 호출은 위와 같은 형식으로 채널 리소스 목록을 반환합니다.

api.example.com/channel/{channel_id}

장점 : 기본 리소스는 하위 항목을 얻기 위해 어디로 가야하는지 노출하지만 (더 RESTful?), 하위 항목을 미리 가져올 필요가 없으며, 하위 목록 생성기 (/ 채널 및 / 멤버)는 인터페이스 (방법과 같은)를 제공합니다. 더 많은 서비스와 같은 응답.
단점 : 이제 개체를 완전히 채우려면 세 번의 호출이 필요합니다.

옵션 4-REST 용 객체 디자인을 (재) 고려

[기존] 응용 프로그램 개체 계층 구조를 재사용하고이를 REST에 적용하려고합니다. 또는 더 직접적으로 API 인터페이스를 제공하려고합니다.

아마도 REST 개체 계층 구조가 달라야하거나 새로운 RESTful 사고가 기존 개체 디자인의 한계를 드러내는 것일 수 있습니다.

위의 모든 의견을 환영합니다.

많은 감사

폴

---

이들을 결합하지 않을 이유가 없습니다.

• api.example.com/user/{user_id} – 사용자 표현을 반환
• api.example.com/channel/{channel_id} – 채널 표현 반환
• api.example.com/user/{user_id}/channels – 채널 표현 목록 반환
• api.example.com/user/{user_id}/channel_list – 채널 ID 목록 (또는 위 링크를 사용하여 전체 표현에 대한 링크)을 반환합니다.

확실하지 않은 경우 "API"문제없이 인간 사용자에게 데이터를 표시하는 방법을 생각해보십시오. 사용자는 인덱스 페이지 ( {user_id}/channel_list)와 전체보기 ( {user_id}/channels)를 모두 원합니다 .

일단 HTML 대신에 (또는 추가로) HTML을 표현 형식으로 지원하면 REST가 있습니다.

---

내가 줄 수있는 가장 좋은 조언은 REST API를 객체 노출로 생각하지 않는 것입니다. 생성 한 리소스는 필요한 사용 사례를 지원해야합니다. 필요한 경우 세 가지 옵션 모두에 대한 리소스를 만들 수 있습니다.

api.example.com/completeuser/{id}
api.example.com/linkeduser/{id}
api.example.com/lightweightuser/{id}

Obviously my names are a bit goofy, but it really doesn't matter what you call them. The idea is that you use the REST api to present data in the most logical way for the particular usage scenario. If there are multiple scenarios, create multiple resources, if necessary. I like to think of my resources more like UI models rather than business entities.

---

I would recommend Restful Obects which is standards for exposing domain model's restful

The idea of Restful Objects is to provide a standard, generic RESTful interface for domain object models, exposing representations of their structure using JSON and enabling interactions with domain object instances using HTTP GET, POST, PUT and DELETE.

According to the standard, the URIs will be like:

• api.example.com/object/user/31
• api.example.com/object/user/31/properties/username
• api.example.com/object/user/31/collections/channels
• api.example.com/object/user/31/collections/members
• api.example.com/object/user/31/actions/someFunction
• api.example.com/object/user/31/actions/someFunction/invoke

There are also other resources

• api.example.com/services
• api.example.com/domain-types

The specification defines a few primary representations:

• object (which represents any domain object or service)
• list (of links to other objects)
• property
• collection
• action
• action result (typically containing either an object or a list, or just feedback messages)
• and also a small number of secondary representations such as home, and user

This is interesting as you’ll see that representations are fully self-describing, opening up the possibility of generic viewers to be implemented if required.

Alternatively, the representations can be consumed directly by a bespoke application.

---

Here's my conclusions from many hours searching and with input from the responders here:

Where I have an object that is effectively a multi-part object, I need to treat that as a single resource. Thus if I GET the object, all the sub-ordinates should be present. This is required in order that the resource is cacheable. If I part load the object (and provide an ETag stamp) then other requestors may receive a partial object when they expected a full one. Conclude - objects should be fully populated if they are being made available as resources.

Associated object relationships should be made available as links to other (primary) resources. In this way the objects are discoverable by traversing the API.

Also, the object hierarchy that made sense for main application site may appear not be what you need to act in RESTful manner, but is more likely revealing problems with the existing hierarchy. Having said this the API may require more specialised use cases than had been previously envisaged, and specialised resources may be required.

Hope that helps someone

참고URL : https://stackoverflow.com/questions/3867344/how-should-i-deal-with-object-hierarchies-in-a-restful-api