ocf core specifiation - open connectivity foundation (ocf)...direitos autorais open connectivity...

Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 1

CONTACT [email protected]

Copyright Open Connectivity Foundation, Inc. © 2016-2017.

All Rights Reserved.

OCF Core Specifiation

VERSION 1.1.0 | June 2017 Part 1


Especificação OpenAPI, conhecida anteriormente como Swagger RESTful API Documentation 562

Specification 563

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md 564 Escape de caractere W3C XML, Extensible Markup Language (XML) 1.0, novembro de 2008 565

http://www.w3.org/TR/2008/REC-xml-20081126/#syntax 566

3 Termos, definições, símbolos e abreviações 567

3.1 Termos e definições 568

3.1.1 569

Cliente 570

uma entidade lógica que acessa um Recurso em um Servidor 571

572

3.1.2 573

Coleção 574

um Recurso que contém zero ou mais Links 575

576

3.1.3 577

Fonte de Configuração 578

uma rede de serviço ou nuvem ou um arquivo de apenas leitura local que contém e 579

fornece informações relacionadas à configuração aos Dispositivos 580

581

3.1.4 582

Recursos Centrais 583

aqueles Recursos que são definidos nesta especificação 584

585

3.1.5 586

Interface Padrão 587

uma Interface usada para gerar a resposta quando uma Interface é omitida em uma solicitação 588

589

3.1.6 590

Dispositivo 591

uma entidade lógica que assume um ou mais Papéis (por exemplo, Cliente, Servidor) 592

Observação 1 da entrada: É possível que mais de um Dispositivo exista em uma plataforma 593

física. 594

595

3.1.7 596

Tipo de Dispositivo 597

uma definição de nome único que indica um conjunto mínimo de Tipos de Recurso que um 598

Dispositivo suporta 599

Observação 1 da entrada: Um Tipo de Dispositivo fornece uma pista sobre o que o Dispositivo 600

é, tal como uma lâmpada ou um ventilador, para uso durante a descoberta de Recurso. 601

602


3.1.8 603

Ponto de Extremidade 604

a fonte ou o destino de uma solicitação e mensagens de resposta para uma determinada Suíte 605

de Protocolo de Transporte 606

Observação 1 da entrada: Um exemplo de uma Suíte de Protocolo de Transporte seria CoAP 607

sobre UDP sobre IPv6. 608

609

3.1.9 610

Entidade 611

um aspecto do mundo físico que é exposto através de um Dispositivo 612

Observação 1 da entrada: Um exemplo de uma entidade é um LED. 613

3.1.10 614

Framework 615

um conjunto de funcionalidades e interações relacionadas definidas nesta especificação, que 616

permite interoperabilidade ao longo de uma ampla gama de dispositivos em rede, incluindo IoT 617

618

3.1.11 619

Interface 620

fornece uma visualização e respostas permissíveis em um Recurso 621

622

3.1.12 623

Introspecção 624

mecanismo para determinar as capacidades dos Recursos hospedados de um Dispositivo 625

626

3.1.13 627

Dados do Dispositivo de Introspecção 628

dados que descrevem as cargas por método implementado dos Recursos que constituem o 629

Dispositivo 630

Observação 1 da entrada: Vide todas as exigências e exceções na seção 11.8 631

632

3.1.14 633

Links 634

estende links da web Digitados conforme a RFC 5988 da IETF 635

636

3.1.15 637

Dispositivo Não OCF 638

621 Um dispositivo que não cumpre com as exigências do Dispositivo OCF 639

640

3.1.16 641

Notificação 642


o mecanismo para cientificar um Cliente quanto a mudanças de estado de recurso em um 643

Recurso 644

645

3.1.17 646

Observar 647

o ato de monitorar um Recurso através de uma solicitação RECUPERAR que é armazenado 648

em cache pelo Servidor que hospeda o Recurso e reprocessado em cada mudança desse 649

Recurso 650

651

3.1.18 652

Parâmetro 653

um elemento que fornece metadados sobre um Recurso referenciado pelo URI alvo de um Link 654

655

3.1.19 656

ATUALIZAÇÃO Parcial 657

uma solicitação ATUALIZAR a um Recurso que inclui um subconjunto das Propriedades que 658

são visíveis através da aplicação da Interface para o Tipo de Recurso 659

660

3.1.20 661

Plataforma 662

um dispositivo físico que contém um ou mais Dispositivos 663

664

3.1.21 665

Cliente de Ponto de Extremidade de Acesso Remoto (R AE) 666

um Cliente que suporta funcionalidade XMPP a fim de acessar um Servidor a partir de uma 667

localização remota 668

669

3.1.22 670

Servidor de Ponto de Extremidade de Acesso Remoto ( RAE) 671

um Servidor que suporta XMPP e é capaz de publicar seu(s) recurso(s) para um servidor 672

XMPP na nuvem, tornando-se assim remotamente endereçável e acessível 673

Observação 1 da entrada: Um Servidor RAE também suporta ICE/STUN/TURN. 674

675

3.1.23 676

Recurso 677

representa uma Entidade modelada e exposta pelo Framework 678

679

3.1.24 680

Diretório de Recursos 681

um conjunto de descrições de Recursos no qual os Recursos reais são mantidos em 682


Servidores externos ao Dispositivo que hospeda o Diretório de Recursos, de forma a permitir 683

que tais recursos sejam pesquisados 684

Observação 1 da entrada: É possível que essa funcionalidade seja usada por Servidores 685

suspensos ou Servidores que optam por não ouvir/responder a solicitações multicast 686

diretamente. 687

688

3.1.25 689

Interface de Recurso 690

uma qualificação das solicitações permitidas em um Recurso 691

692

3.1.26 693

Propriedade de Recurso 694

um aspecto ou parâmetro significativo de um recurso, incluindo metadados, que é exposto 695

através do Recurso 696

697

3.1.27 698

Tipo de Recurso 699

uma definição de nome único de uma classe de Propriedades de Recurso e as interações que 700

são suportadas por essa classe 701

Observação 1 da entrada: Cada Recurso tem uma Propriedade “rt” cujo valor é o nome único 702

do Tipo de Recurso. 703

3.1.28 704

Cena 705

uma entidade estática que armazena um conjunto de valores de propriedade de Recurso 706

definidos para uma coleção de Recursos 707

Observação 1 da entrada: Uma Cena é uma configuração estipulada de um conjunto de 708

recursos, sendo que cada um tem um valor predeterminado para a propriedade que tem que 709

ser mudada. 710

711

3.1.29 712

Coleção de Cenas 713

uma coleção de Recursos que contém uma enumeração de possíveis Valores de Cena e o 714

Valor de Cena atual 715

Observação 1 da entrada: Os valores-membros do Recurso da coleção de Cenas são 716

Membros da Cena. 717

718

3.1.30 719

Membro da Cena 720

um Recurso que contém mapeamentos de Valores de Cena para valores de uma propriedade 721

no recurso 722


723

3.1.31 724

Valor de Cena 725

um enumerador de Cena que representa o estado em que é possível que um Recurso esteja 726

727

3.1.32 728

Servidor 729

um Dispositivo com o papel de fornecer informações de estado de recurso e facilitar interação 730

remota com seus recursos 731

Observação 1 da entrada: É possível implementar um Servidor para expor recursos de 732

Dispositivo não OCF para Clientes (seção 5.6) 733

734

3.1.33 735

Tipo de Recurso Vertical 736

um Tipo de Recurso em uma especificação de domínio vertical 737

Observação 1 da entrada: Um exemplo de um Tipo de Recurso Vertical seria 738

“oic.r.switch.binary”. 739

740

3.2 Símbolos e abreviações 741

3.2.1 742

ACL 743

Lista de Controle de Acesso 744

Observação 1 da entrada: Os detalhes são definidos na Segurança OCF. 745

746

3.2.2 747

CBOR 748

Representação de Objeto Binário Conciso 749

750

3.2.3 751

CoAP 752

Protocolo de Aplicação Restrita 753

754

3.2.4 755

EXI 756

Intercâmbio XML Eficiente 757

758

3.2.5 759

IRI 760

Identificadores de Recursos Internacionalizados 761

762


3.2.6 763

ISP 764

Provedor de Serviço de Internet 765

766

3.2.7 767

JSON 768

Notação de Objeto JavaScript 769

770

3.2.8 771

mDNS 772

Serviço de Nome de Domínio Multicast 773

774

3.2.9 775

MTU 776

Unidade de Transmissão Máxima 777

778

3.2.10 779

NAT 780

Tradução de Endereço de Rede 781

782

3.2.11 783

OCF 784

Open Connectivity Foundation 785

a organização que criou esta especificação 786

787

3.2.12 788

RAML 789

Linguagem de Modelagem de API RESTful 790

791

3.2.13 792

REST 793

Transferência de Estado Representacional 794

3.2.14 795

RESTfull 796

serviços da Web compatíveis com REST 797

798

3.2.15 799

URI 800

Identificador de Recurso Uniforme 801

802


3.2.16 803

URN 804

Nome de Recurso Uniforme 805

806

3.2.17 807

UTC 808

Horário Universal Coordenado 809

810

3.2.18 811

UUID 812

Identificador Único Universal 813

814

3.2.19 815

XML 816

Linguagem de Marcação Extensível 817

3.3 Convenções 818

Nesta especificação, alguns termos, condições, mecanismos, sequências, parâmetros, 819

eventos, estados ou termos semelhantes são impressos com a primeira letra de cada palavra 820

em letra maiúscula e as demais em letras minúsculas (por exemplo, Arquitetura de Rede). 821

Quaisquer usos em letras minúsculas dessas palavras têm o significado técnico em inglês 822

normal. 823

3.4 Tipos de dados 824

Os recursos são definidos através do uso de tipos de dados derivados de valores JSON, 825

conforme definido em ECMA-4-4. Contudo, é possível que um Recurso sobrecarregue um valor 826

JSON definido para especificar um subconjunto particular do valor JSON, através do uso de 827

palavras-chave de validação definidas em [Validação do schema JSON]. 828

829

Entre outras palavras-chave de validação, a seção 7 de [Validação de schema JSON] define 830

uma palavra-chave “format” com alguns atributos de formato, tais como “uri” e “date-time”, e 831

uma palavra-chave “pattern” com uma expressão regular a qual é possível usar para validar 832

uma cadeia. Esta seção define padrões que estão disponíveis para uso na descrição de 833

Recursos OCF. É possível usar os nomes de padrão em textos de especificação nos quais é 834

possível que os nomes de formato JSON ocorram. Ao invés disso, os schemas JSON reais 835

precisam usar o tipo e o padrão JSON. 836

837

Para todas as linhas definidas na Tabela 1 abaixo, o tipo JSON é cadeia. 838

839

Tabela 1. Tipos OCF Adicionais 840

Nome do Padrão Padrão Descrição


841

As cadeias precisam ser codificadas como UTF-8, a menos que especificado de outra forma. 842

843

Em um schema JSON, “maxLength” para uma cadeia indica o número máximo de caracteres 844

não octetos. Contudo, “maxLength” também precisa indicar o número máximo de octetos. Caso 845

nenhum “maxLength” seja definido para uma cadeia, então o comprimento máximo precisa ser 846

64 octetos. 847

848

4 Convenções e organização do documento 849

850

Neste documento, as características são descritas como exigido, recomendado, permitido ou 851

OBSOLETO conforme segue. 852

853

Exigido (ou “precisa” ou “obrigatório”) (M). 854

• Essas características básicas precisam ser implementadas para se adequar à Arquitetura 855

Central. As expressões “não pode” e “PROIBIDO” indicam comportamento que é proibido, ou 856

seja, que se realizado significa que a implementação não está em conformidade. 857

858

Recomendado (ou deve)(S). 859

• Essas características acrescentam funcionalidades suportadas pela Arquitetura Central e 860

devem ser implementadas. Características recomendadas se beneficiam das capacidades da 861

Arquitetura Central, geralmente sem impor um grande aumento de complexidade. Observe que 862

para teste de adequação, se uma característica recomendada é implementada, ela deve 863

atender às exigências especificadas para estar em adequação com estas diretrizes. É possível 864

que algumas características recomendadas se tornem exigências no futuro. A expressão “não 865

deve” indica comportamento que é permitido, mas não recomendado. 866

867

Permitido (pode ou permitido)(O). 868

• Essas características não são nem exigidas e nem recomendadas pela Arquitetura Central, 869

mas se a característica for implementada, ela precisa cumprir com as exigências especificadas 870

para estar em adequação com estas diretrizes. 871

OBSOLETO. 872

873

• Embora essas características ainda sejam descritas nesta especificação, elas não devem ser 874


implementadas, exceto para fins de retrocompatibilidade. A ocorrência de uma característica 875

obsoleta durante a operação de uma implementação que se adequa à especificação atual não 876

tem efeito sobre a operação da implementação e não produz quaisquer condições de erro. 877

Retrocompatibilidade pode exigir que uma característica seja implementada e funcione 878

conforme especificado, mas ela nunca pode ser usada por implementações que se adequem a 879

esta especificação. 880

881

Permitido condicionalmente (CA) 882

• A definição ou comportamento depende de uma condição. Se a condição especificada for 883

cumprida, então a definição ou o comportamento são permitidos, caso contrário, não são 884

permitidos. 885

886

Exigido condicionalmente (CR) 887

• A definição ou comportamento depende de uma condição. Se a condição especificada for 888

cumprida, então a definição ou o comportamento são exigidos. Caso contrário, a definição ou o 889

comportamento são permitidos como padrão, a menos que definidos especificamente como 890

não permitidos. 891

892

Cadeias a serem tomadas literalmente aparecem entre “aspas”. 893

894

Palavras que são enfatizadas são impressas em itálico. 895

896

5 Arquitetura 897

5.1 Visão Geral 898

A arquitetura permite interações com base em recurso entre artefatos IoT, ou seja, dispositivos 899

ou aplicações físicos. A arquitetura alavanca padrões e tecnologias de indústria existentes e 900

fornece soluções para o estabelecimento de conexões (sem fio ou com fio) e o gerenciamento 901

do fluxo de informações entre dispositivos, independentemente de seus fatores de forma, 902

sistemas operacionais ou provedores de serviço. 903

Especificamente, a arquitetura fornece: 904

• Um framework de comunicação e interoperabilidade para múltiplos segmentos de mercado 905

(Consumidor, Empresarial, Industrial, Automotivo, Saúde, etc.), sistemas operacionais, 906

plataformas, modos de comunicação, transportes e casos de uso 907

• Um modelo comum e consistente para descrever o ambiente e permitir interoperabilidade de 908

informações e semântica 909

• Protocolos de comunicação comum para descoberta e conectividade 910

• Mecanismos comuns de segurança e identificação 911

• Oportunidade de inovação e diferenciação de produtos 912

• Uma solução escalável que aborda diferentes capacidades de dispositivo, aplicável a 913

dispositivos inteligentes, bem como as menores coisas conectadas e dispositivos que podem 914


ser usados junto ao corpo 915

916

A arquitetura se baseia nos princípios de design da Arquitetura Voltada para Recurso descritos 917

nas seções 5.2 até 5.6, respectivamente. A seção 5.2 apresenta os princípios orientadores 918

para operações OCF. A seção 5.3 define o Framework e diagrama de bloco funcional. A seção 919

5.5 fornece um cenário de exemplo com papéis. A Seção 5.6 fornece um cenário 920

exemplificativo de ponte para ecossistema não OCF. 921

922

5.2 Princípio 923

Na arquitetura, Entidades no mundo físico (por exemplo, sensor de temperatura, uma lâmpada 924

elétrica ou um utensílio doméstico) são representadas como recursos. Interações com uma 925

Entidade são alcançadas através de suas representações de recurso (seção 7.7) através do 926

uso de operações que adiram ao estilo arquitetural de Transferência de Estado 927

Representacional (REST), ou seja, interações RESTful. 928

929

A arquitetura define a estrutura geral do Framework como um sistema de informações e os 930

inter-relacionamentos das Entidades que compõem o OCF. As Entidades são expostas como 931

Recursos, com seus identificadores únicos (URIs) e suportam interfaces que permitem 932

operações RESTful nos Recursos. Toda operação RESTful tem um iniciador da operação (o 933

cliente) e um respondente à operação (o servidor). No Framework, a noção do cliente e do 934

servidor é realizada através de papéis (seção 5.5). É possível a qualquer dispositivo atuar 935

como um Cliente e iniciar uma operação RESTful em qualquer Dispositivo que atue como um 936

Servidor. Se forma similar, qualquer Dispositivo que exponha Entidades como Recursos atua 937

como um Servidor. Em conformidade com o estilo arquitetural REST, cada operação RESTful 938

contém todas as informações necessárias para entender o contexto da interação e é acionada 939

através do uso de um pequeno conjunto de operações genéricas, ou seja, CRIAR, 940

RECUPERAR, ATUALIZAR, EXCLUIR e NOTIFICAR (CRUDN) definidas na seção 8, que 941

inclui representações de Recursos. 942

943

A figura 1 retrata a arquitetura. 944


945

946

A arquitetura é organizada conceitualmente em três aspectos principais que fornecem 947

separação geral de assunto: modelo de recurso, operações RESTful e abstrações. 948

949

• Modelo de recurso: O modelo de recurso fornece as abstrações e os conceitos exigidos para950

modelar logicamente e operar logicamente na aplicação e em seu ambiente. O modelo de 951

recurso central 952

é comum e independente em relação a qualquer domínio de aplicação específica, tal como de 953

casa inteligente, industrial ou automotivo. Por exemplo, o modelo de recurso define um 954

Recurso que abstrai uma Entidade e a representação de um Recurso mapeia o estado da 955

Entidade. É possível usar outros conceitos de modelo de recurso para modelar outros 956

aspectos, por exemplo, comportamento. 957

• Operações RESTful: As operações CRUDN genéricas são definidas através do uso de958

paradigma RESTful para modelar as interações com um Recurso de forma independente em 959

relação a protocolo e tecnologia. Os protocolos específicos de comunicação ou envio de 960

mensagens são parte da abstração de protocolo e o mapeamento de Recursos para protocolos 961

específicos é fornecido na seção 11.8. 962

• Abstração: As abstrações no modelo de recurso e as operações RESTful são mapeadas para963

elementos concretos que usam primitivos de abstração. Um manipulador de entidade é usado 964

para mapear uma Entidade para um Recurso e primitivos de abstração de conectividade são 965

usados para mapear operações lógicas RESTful para protocolos de conectividade de dados ou 966

tecnologias. Manipuladores de entidade também podem ser usados para mapear Recursos 967

para Entidades que são atingidas sobre protocolos que não são suportados pelo OCF. 968

969


5.3 Diagrama de bloco funcional 970

O diagrama de bloco funcional abrange todas as funcionalidades exigidas para operação. 971

Essas funcionalidades são categorizadas como perfis de conectividade L2, rede, transporte, 972

Framework e aplicação. Os blocos funcionais são retratados na Figura 2 e listados abaixo. 973

974

Figura 2: Diagrama de bloco funcional 975

•Conectividade L2: Fornece as funcionalidades exigidas para estabelecimento de conexões 976

de camada de ligação física e de dados (por exemplo, conexão Wi-FiTM ou Bluetooth®) à rede. 977

•Rede: Fornece funcionalidades exigidas para Dispositivos para troca de dados entre si na rede 978

(por exemplo, Internet). 979

•Transporte : Fornece transporte de fluxo ponta-a-ponta com restrições QoS específicas. 980

Exemplos de um protocolo de transporte incluem TCP e UDP ou novos protocolos de 981

Transporte sob desenvolvimento na IETF, por exemplo, Redes Tolerantes a Atraso (DTN). 982

•Framework : Fornece as funcionalidades centrais conforme definido nesta especificação. O 983

bloco funcional é a fonte de solicitações e respostas que são o conteúdo da comunicação entre 984

dois Dispositivos. 985

• Perfil de aplicação: Fornece modelos de dados e funcionalidades específicos de segmentos 986

de mercado, por exemplo, modelos de dados e funções de casa inteligente para o segmento de 987

mercado de casas inteligentes. 988

989

Quando dois Dispositivos se comunicam entre si, cada bloco funcional em um Dispositivo 990

interage com sua contraparte no Dispositivo par conforme mostrado na Figura 3. 991


992

5.4 Framework 993

Framework consiste em funções que fornecem funcionalidades centrais para operação. 994

1) Identificação e endereçamento. Define o identificador e a capacidade de endereçamento. 995

A função de Identificação e endereçamento é definida na seção 6. 996

2) Descoberta. Define o processo para descoberta disponível 997

a) Dispositivos (Descoberta de Ponto de Extremidade na seção 10) e 998

b) Recursos (descoberta de Recurso na seção 11.3) 999

3) Modelo de recurso . Especifica a capacidade de representação de Entidades em termos de 1000

recursos e define mecanismos para manipular os recursos. A função de modelo de recurso é 1001

definida na seção 7. 1002

4) CRUDN. Fornece um esquema genérico para as interações entre um Cliente e o Servidor 1003

conforme definido na seção 8. 1004

5) Envio de Mensagens . Fornece protocolos de mensagem específicos para operação 1005

RESTful, ou seja, CRUDN. Por exemplo, CoAP é um protocolo de mensagem primário. A 1006

função de mensagem é definida na seção 11.8. 1007

6) Gerenciamento de dispositivo. Especifica a disciplina de gerenciamento das capacidades 1008

de um Dispositivo e inclui configuração inicial e de provisionamento de dispositivo, bem como 1009

diagnóstico e monitoramento de dispositivo. A função de gerenciamento de dispositivo é 1010

definida na seção 11.5. 1011

7) Segurança. Inclui mecanismos de autenticação, autorização e controle de acesso exigidos 1012

para garantir acesso a Entidades. A função de segurança é definida da seção 13. 1013

1014

5.5 Cenário Exemplificativo com papéis 1015

Interações são definidas entre entidades lógicas conhecidas como Papéis. Três papéis são 1016

definidos: Cliente, Servidor e Intermediário. 1017

1018

A Figura 4 ilustra um exemplo dos Papéis em um cenário no qual um telefone inteligente envia 1019


uma mensagem de solicitação para um termostato; a solicitação original é enviada por HTTP, 1020

mas é traduzida em uma mensagem de solicitação CoAP por um gateway entre ambos, e 1021

então entregue ao termostato. Neste exemplo, o telefone inteligente assume o papel de um 1022

Cliente, o gateway assume o papel de um intermediário e o termostato assume o papel de um 1023

Servidor. 1024

1025

5.6 Cenário Exemplificativo: Ponte para ecossistema não OCF 1026

O caso de uso para este cenário é um mostrador (como um relógio de pulso) que é usado para 1027

monitorar um sensor de pulsação que implementa um protocolo que não é suportado pelo 1028

OCF. 1029

A Figura 5 fornece uma vista lógica detalhada dos conceitos descritos na Figura 1. 1030

1031

Os detalhes podem ser implementados de várias formas, por exemplo, através do uso de um 1032

Servidor com um manipulador de entidade para realização de interface direta com um 1033

dispositivo não OCF, como mostrado na Figura 6. 1034


1035

Na inicialização, o Servidor executa os manipuladores de entidade que descobrem os sistemas 1036

não OCF (por exemplo, Dispositivo Sensor de Pulsação) e criam recursos para cada dispositivo 1037

ou funcionalidade descoberta. O manipulador de entidade cria um Recurso para cada 1038

dispositivo ou funcionalidade descobertos e se vincula a tal Recurso. Esses recursos são 1039

tornados passíveis de descoberta pelo Servidor. 1040

1041

Uma vez que os recursos são criados e tornados passíveis de descoberta, então o Dispositivo 1042

Mostrador é capaz de descobrir esses recursos e operar sobre os mesmos através do uso dos 1043

mecanismos descritos nesta especificação. As solicitações para um recurso no Servidor são 1044

então interpretadas pelo manipulador de entidade e encaminhadas para o dispositivo não OCF 1045

que usa o protocolo suportado pelo dispositivo não OCF. As informações retornadas do 1046

dispositivo não OCF são então mapeadas para a resposta apropriada para tal recurso. 1047

1048

6 Identificação e endereçamento 1049

6.1 Introdução 1050

A facilitação de interações apropriadas e eficientes entre elementos no Framework exige um 1051

meio para identificar, nomear e endereçar esses elementos. 1052

1053

O identificador identifica de forma não ambígua um elemento em um contexto ou domínio. O 1054

contexto ou domínio podem ser determinados pelo uso ou pela aplicação. Espera-se que o 1055

identificador seja imutável ao longo do ciclo de vida de tal elemento e não seja ambíguo dentro 1056

de um contexto ou domínio. 1057

1058

O endereço é usado para definir um lugar, forma ou meio de atingir ou acessar o elemento a 1059

fim de interagir com o mesmo. Um endereço pode ser mutável com base no contexto. 1060

1061

O nome é uma alça que distingue o elemento de outros elementos no framework. O nome pode 1062

ser mudado ao longo do ciclo de vida de tal elemento. 1063

1064

É possível que haja métodos ou esquemas de resolução que permitam a determinação de 1065

qualquer um dos mesmos com base no conhecimento de um ou mais dos outros (por exemplo, 1066

determinação do nome a partir do endereço ou do endereço a partir do nome). 1067

1068

Cada um desses aspectos pode ser definido separadamente para múltiplos contextos (por 1069


exemplo, é possível que um contexto seja uma camada em uma pilha). Assim, um endereço 1070

pode ser um URL para endereçamento de recurso e um endereço de IP para endereçamento 1071

na camada de conectividade. Em algumas situações, ambos os endereços seriam exigidos. 1072

Por exemplo, para realizar a operação RECUPERAR (seção 8.3) em uma representação de 1073

recurso particular, é necessário que o cliente saiba o endereço do recurso alvo e o endereço do 1074

servidor através do qual o recurso é exposto. 1075

1076

Em um contexto ou domínio de uso, é possível que um nome ou endereço seja usado como 1077

identificador ou vice-versa. Por exemplo, é possível que um URL seja usado como um 1078

identificador para um recurso e designado como um URI. 1079

1080

O restante desta seção trata do identificador, do endereço e da nomeação sob o ponto de vista 1081

do modelo de recurso e das interações a serem suportadas pelo modelo de recurso. Exemplos 1082

de interações são as interações RESTful, ou seja, operação CRUDN (seção 8) em um recurso. 1083

Ademais, o mapeamento desses para protocolos de transporte, por exemplo, CoAP, é descrito. 1084

1085

6.2 Identificação 1086

Um identificador não é ambíguo dentro do contexto ou domínio de uso. Há vários esquemas 1087

que pode ser usados para gerar um identificador que tenha as propriedades exigidas. O 1088

identificador pode ser específico do contexto em que se espera que o identificador esteja e 1089

pode ser certamente não ambíguo apenas dentro do contexto ou domínio. O identificador 1090

também pode ser independente de contexto caso seja garantido que esses identificadores não 1091

sejam ambíguos ao longo de todos os contextos e domínios, tanto espacialmente quanto 1092

temporalmente. É possível definir os identificadores específicos de contexto através de 1093

esquemas simples como enumeração monotônica, ou tais identificadores podem ser definidos 1094

através da sobrecarga de um endereço ou nome. Por exemplo, um endereço de IP pode ser 1095

um identificador dentro do domínio privado por trás de um gateway em uma casa inteligente. 1096

Por outro lado, identificadores independentes de contexto exigem um esquema mais forte que 1097

derive identidades universalmente únicas, por exemplo, quaisquer das versões dos 1098

Identificadores Universalmente Únicos (UUIDs). O identificador independente de contexto 1099

também pode ser gerado através do uso de hierarquia de domínios, em que a raiz da 1100

hierarquia é identificada com um UUID e subdomínios podem gerar identificadores 1101

independentes de contexto através da concatenação de identificadores específicos de contexto 1102

para tal domínio ao identificador independente de contexto de seu pai. 1103

1104

6.2.1 Identificação e endereçamento de recurso 1105

Um recurso pode ser identificado através do uso de um URI e endereçado pelo mesmo URI se 1106

o URI for um URL. Em alguns casos um recurso pode necessitar de um identificador que seja 1107

diferente de um URI; nesse caso, o recurso pode ter uma propriedade cujo valor seja o 1108

identificador. Quando o URI está na forma de um URL, então o URI pode ser usado para 1109


endereçar o recurso. 1110

1111

Um URI de OCF é baseado na forma geral de um URI conforme definido na RFC 3986 da IETF 1112

da seguinte forma: 1113

:///? 1114

1115

Especificamente, o URI de OCF é especificado na seguinte forma: 1116

ocf :///? 1117

1118

Uma descrição dos valores que cada componente assume é fornecida abaixo. 1119

O esquema para o URI é ‘ocf’. O esquema ‘ocf’ representa a semântica, as definições e o uso, 1120

conforme definido neste documento. Se um URI tem a parte que precede ‘//’ (barra dupla) 1121

omitida, então o esquema ‘ocf’ deve ser presumido. 1122

1123

Cada associação de transporte é responsável por especificar como um URI de OCF é 1124

convertido em um URI de protocolo de transporte antes do envio pela rede pelo solicitante. De 1125

forma semelhante no lado do destinatário, cada associação de transporte é responsável por 1126

especificar como um URI de OCF é convertido a partir de um URI de protocolo de transporte 1127

antes de transferir para a camada de modelo de recurso no destinatário. 1128

1129

A autoridade de um URI de OCF precisa ser o valor da ID do Dispositivo (“di”), conforme 1130

definido em [Segurança OCF], do Servidor. 1131

1132

O caminho é uma cadeia que identifica de forma não ambígua ou faz referência a um recurso 1133

dentro do contexto do Servidor. Nesta versão da especificação, um caminho não pode incluir 1134

caracteres não ASCII codificados por cento ou caracteres nulos. Um caminho precisa ser 1135

precedido por um ‘/’ (barra). O caminho pode ter segmentos separados por ‘/’ (barra) para fins 1136

de legibilidade humana. No contexto OCF, os segmentos separados por ‘/’ (barra) são tratados 1137

como uma cadeia única que faz referência direta aos recursos (ou seja, uma estrutura plana) e 1138

não analisada como uma hierarquia. No Servidor, o caminho ou alguma subcadeia no caminho 1139

podem ser encurtados através do uso de hash ou algum outro esquema, desde que a 1140

referência resultante seja única dentro do contexto do host. 1141

1142

Uma vez que um caminho é gerado, um Cliente que acessa o recurso ou recipiente do URI 1143

deve usar tal caminho como uma cadeia opaca e não deve analisar para inferir uma estrutura, 1144

organização ou semântica. 1145

1146

Uma cadeia de consulta precisa conter uma lista de segmentos = (também 1147

conhecida como “par nome-valor”), sendo cada um separado por um ‘&’ (“E” comercial). A 1148

cadeia de consulta será mapeada para a sintaxe apropriada do protocolo usado para envio de 1149


mensagens. (por exemplo, CoAP). 1150

1151

Um URI pode ser 1152

• Totalmente qualificado ou 1153

• Relativo 1154

1155

Geração de URI: 1156

Um URI pode ser definido pelo Cliente que é o criador de tal recurso. Tal URI pode ser relativo 1157

ou absoluto (totalmente qualificado). Um URI relativo precisa ser relativo ao Dispositivo no qual 1158

ele é hospedado. Alternativamente, um URI pode ser gerado pelo Servidor de tal recurso 1159

automaticamente com base em uma convenção ou organização predefinida dos recursos, com 1160

base uma interface, com base em algumas regras ou com relação a diferentes raízes ou bases. 1161

1162 Uso do URI: 1163

A referência de caminho absoluto de um URI tem que ser tratada como uma cadeia opaca e 1164

um Cliente não deve inferir nenhuma estrutura explícita ou implícita no URI - o URI é 1165

simplesmente um endereço. Recomenda-se também que Dispositivos que hospedam um 1166

recurso tratem o URI de cada recurso como uma cadeia opaca que endereça apenas tal 1167

recurso. (por exemplo, os URI’s /a e /a/b são considerados como endereços distintos e não é 1168

possível interpretar o recurso b como um filho do recurso a). 1169

1170

6.3 Namespace: 1171

O prefixo de URI relativo “/oic/” é reservado como um namespace para URIs definidos em 1172

especificações OCF e não pode ser usado para URIs que não sejam definidos em 1173

especificações OCF. 1174

1175

6.4 Endereçamento de rede 1176

Seguem os endereços usados nesta especificação: 1177

1178

• Endereço de IP 1179

Um endereço de IP é usado quando o dispositivo usa uma interface com IP configurado. 1180

Quando um Dispositivo tem apenas as informações de identidade de seu par, um mecanismo 1181

de resolução é necessário para mapear o identificador para o endereço correspondente. 1182

1183

7 Modelo de recurso 1184

7.1 Introdução 1185

O Modelo de Recurso define conceitos e mecanismos que fornecem consistência e 1186

interoperabilidade central entre dispositivos nos ecossistemas OCF. O conceitos e mecanismos 1187

do Modelo de Recurso são então mapeados para os protocolos de transporte para permitir a 1188

comunicação entre os dispositivos - cada transporte fornece a interoperabilidade de protocolo 1189

de comunicação. O Modelo de Recurso, portanto, permite que a interoperabilidade seja 1190


definida de forma independente dos transportes. 1191

1192

Além disso, os conceitos no Modelo de Recurso suportam modelagem dos artefatos primários 1193

e seus relacionamentos entre si e capturam as informações semânticas exigidas para 1194

interoperabilidade em um contexto. Dessa forma, o OCF vai além da simples interoperabilidade 1195

de protocolo para capturar a rica semântica exigida para verdadeira interoperabilidade em 1196

ecossistemas de Produtos que Podem ser Usados Junto ao Corpo e Internet das Coisas. 1197

1198

Os conceitos primários no Modelo de Recurso são: Entidade, Recursos, Identificadores de 1199

Recurso Uniformes (URI), Tipos de Recurso, Propriedades, Representações, Interfaces, 1200

Coleções e Links. Além disso, os mecanismos gerais são CRIAR, RECUPERAR, ATUALIZAR, 1201

EXCLUIR e NOTIFICAR. Esses conceitos e mecanismos podem ser compostos de várias 1202

formas para definir a rica semântica e interoperabilidade necessárias para um conjunto diverso 1203

de casos de uso aos quais o framework OCF é aplicado. 1204

1205

No framework do Modelo de Recurso OCF, uma Entidade necessita ser visível, interagida ou 1206

manipulada, ela é representada por uma abstração denominada Recurso. Um Recurso 1207

encapsula e representa o estado de uma Entidade. Um Recurso é identificado, endereçado 1208

e nomeado através do uso de URIs. 1209

1210

As propriedades são pares “chave=valor” e representam o estado do Recurso. Um instantâneo 1211

dessas Propriedades é a Representação do Recurso. Uma vista específica da Representação 1212

e dos mecanismos aplicáveis em tal vista são especificados como Interfaces. Interações com 1213

um Recurso são feitas como Solicitações e Respostas que contêm Representações. 1214

1215

Uma instância de recurso é derivada de um Tipo de Recurso. O relacionamento unidirecional 1216

entre um Recurso e outro Recurso é definido como um Link. Um Recurso que tem 1217

Propriedades e Links é uma Coleção. 1218

1219

É possível usar um conjunto de Propriedades para definir um estado de um Recurso. Este 1220

estado pode ser recuperado ou atualizado através do uso de Representações apropriadas 1221

respectivamente na resposta de tal Recurso e na solicitação a tal Recurso. 1222

1223

É possível que um Recurso (e Tipo de Recurso) represente e seja usado para expor uma 1224

capacidade. É possível usar interações com tal Recurso para exercer ou usar tal capacidade. É 1225

possível usar tais capacidades para definir processos como descoberta, gerenciamento, 1226

divulgação etc. Por exemplo: É possível definir “descoberta de recursos em um dispositivo” 1227

como a recuperação de uma representação de um recurso específico em que uma propriedade 1228

ou propriedades tem (têm) valores que descrevem ou fazem referência aos recursos no 1229

dispositivo. 1230


1231

As informações para Solicitação ou Resposta com a Representação podem ser comunicadas 1232

“com fio” através de serialização, utilizando-se um protocolo de transferência ou encapsuladas 1233

na carga do protocolo de transporte - o método específico é determinado pelo mapeamento 1234

normativo da Solicitação ou Resposta ao protocolo de transporte. Vide protocolos de transporte 1235

suportados na seção 11.8. 1236

1237

As definições RAML usadas neste documento são normativas. Isso também inclui o fato de que 1238

todas as cargas JSON definidas precisam se adequar ao schema JSON indicado. Vide os 1239

Tipos de Recurso definidos nesta especificação no Anexo D. 1240

1241

7.2 Recurso 1242

Um Recurso precisa ser definido por um ou mais Tipo(s) de Recurso - vide o Tipo de Recurso 1243

no Anexo D. Uma solicitação para CRIAR um Recurso precisa especificar um ou mais Tipos de 1244

Recurso que definem esse Recurso. 1245

1246

Um Recurso é hospedado em um Dispositivo. Um Recurso precisa ter um URI, conforme 1247

definido na seção 6. O URI pode ser atribuído pela Autoridade na criação do Recurso ou pode 1248

ser predefinido pela especificação do Tipo de Recurso. 1249

1250

Recursos Centrais são os Recursos definidos nesta especificação para permitir interações 1251

funcionais conforme definido na seção 10 (por exemplo, Descoberta, Gerenciamento de 1252

Dispositivo, etc.). Entre os Recursos Centrais, “/oic/res”, “/oic/p” e “/oic/d” precisam ser 1253

suportados em todos os Dispositivos. Dispositivos podem suportar outros Recursos Centrais, 1254

dependendo das interações funcionais eles suportam. 1255

1256

7.3 Propriedade 1257

7.3.1 Introdução 1258

Uma Propriedade descreve um aspecto que é exposto através de um Recurso, incluindo 1259

metainformações relacionadas a tal recurso. 1260

1261

Uma Propriedade precisa ter um nome, ou seja, Nome de Propriedade e um valor, ou seja, 1262

Valor de Propriedade. A Propriedade é expressa como um par de valores-chave, em que a 1263


chave é o Nome de Propriedade e o valor é o Valor de Propriedade, como = . Por exemplo, se a Propriedade “temperature” tem um 1265

Nome de Propriedade “temp” e um Valor de Propriedade “30F”, então a Propriedade é 1266

expressa como “temp=30F”. O formato específico da Propriedade depende do esquema de 1267

codificação. Por exemplo, em JSON, Propriedade é representada como “chave”: valor (por 1268

exemplo, “temp”: 30). 1269

1270

Além disso, a definição de Propriedade precisa ter um 1271

• Tipo de Valor - o Tipo de Valor define os valores que um Valor de Propriedade pode assumir. 1272

O Tipo de Valor pode ser um tipo de dados simples (por exemplo, cadeia, Boolean) conforme 1273

definido na seção 3.4 ou pode ser um tipo de dados complexo definido com um schema. O 1274

Tipo de Valor pode definir 1275

o As Regras de Valor definem as regras para o conjunto de valores que o Valor de 1276

Propriedade pode assumir. Tais regras podem definir a faixa de valores, o mínimo-1277

máximo, fórmulas, conjunto de valores enumerados, padrões, valores condicionais e 1278

até dependências de valores de outras Propriedades. As regras podem ser usadas 1279

para validar os valores específicos em um Valor de Propriedade e sinalizar erros. 1280

• Obrigatório - especifica se a Propriedade é obrigatória ou não para um determinado Tipo de 1281

Recurso. 1282

• Modos de acesso - especifica se a Propriedade pode ser lida, escrita ou ambas. 1283

Atualizações são equivalentes a uma gravação. “r” é usado para leitura e “w” é usado para 1284

gravação - ambos podem ser especificados. Gravação não implica automaticamente em leitura. 1285

A definição de uma Propriedade pode incluir as seguintes informações adicionais - esses itens 1286

são informativos: 1287

• Título da Propriedade - um nome amigável para humanos para designar a Propriedade; 1288

geralmente não enviado por fio 1289

• Descrição - texto descritivo que define a finalidade e o uso esperado dessa Propriedade. 1290

Uma Propriedade pode ser usada na parte de consulta de um URI como um critério para 1291

seleção de um Recurso particular. Isso é feito declarando-se a Propriedade (ou seja, = ) como um dos segmentos da consulta. 1293

Nesta versão da especificação, apenas cadeias ASCII são permitidas em filtros de consulta e 1294

os caracteres nulos são proibidos em filtros de consulta. Isso significa que é possível combinar 1295

apenas os valores de propriedade com caracteres ASCII em um filtro de consulta. O Recurso é 1296

selecionado quando todas as Propriedades declaradas na consulta combinam com as 1297

Propriedades correspondentes na Representação completa do Recurso alvo. A Representação 1298

completa é o instantâneo que inclui a união de todas as Propriedades em todos os Tipos de 1299

Recurso que definem o Recurso alvo. Se a Propriedade é declarada no segmento “filtro” da 1300

consulta, então a Propriedade declarada é combinada com a Representação definida pela 1301

Interface para isolar determinadas partes de tal Representação. 1302

1303


Em geral, uma propriedade é significativa apenas dentro do recurso ao qual ela é associada. 1304

Contudo um conjunto base de propriedades que pode ser suportado por todos os Recursos, 1305

conhecido como Propriedades Comuns, mantém a sua semântica intacta ao longo dos 1306

Recursos, ou seja, seu par “chave=valor” tem o mesmo significado em qualquer Recurso. 1307

Tabelas detalhadas com os campos acima para todas as propriedades comuns são definidas 1308

na seção 1309

1310

7.3.2. Propriedades Comuns 1311

7.3.2.1 Introdução 1312

As Propriedades Comuns definidas nesta seção podem ser especificadas para todos os 1313

Recursos. As seguintes Propriedades são definidas como Propriedades Comuns: “Tipo de 1314

Recurso”, “Interface de Recurso”, “Nome”, e “Identidade de Recurso”. 1315

1316

O nome de uma Propriedade Comum precisa ser único e não pode ser usado por outras 1317

propriedades. Ao definir um novo Tipo de Recurso, suas propriedades não comuns não podem 1318

usar o nome de Propriedades Comuns existentes (por exemplo, “rt”, “if”, “n”, “id”). Ao definir 1319

uma nova “Propriedade Comum”, deve-se garantir que o seu nome não tenha sido usado por 1320

quaisquer outras propriedades. É possível verificar a unicidade de um novo nome de 1321

Propriedade Comum através da conferência de todas as Propriedades de todos os Tipos de 1322

Recurso definidos por OCF existentes. Contudo, isso pode se tornar trabalhoso à medida que o 1323

número de Tipos de Recurso cresce. Para evitar tais conflitos de nome no futuro, o OCF pode 1324

reservar um determinado espaço de nome para propriedade comum. Possíveis abordagens 1325

são (1) um prefixo específico (por exemplo, “oic”) pode ser designado e o nome precedido pelo 1326

prefixo (por exemplo, “oic.psize”) é apenas para Propriedade Comum; (2) os nomes que 1327

consistem em uma ou duas letras são reservados para Propriedade Comum e todas as outras 1328

Propriedades precisam ter o nome com o comprimento maior que as 2 letras; (3) Propriedades 1329

Comuns podem ser aninhadas sob objeto específico para se distinguirem. 1330

1331

A capacidade de ATUALIZAR uma Propriedade Comum (que suporta gravação como um modo 1332

de acesso) é restrita à Interface “oic.if.rw” (leitura-gravação); assim, uma Propriedade Comum 1333

precisa ser atualizável através do uso da Interface leitura-gravação se e somente se a 1334

Propriedade suporta acesso de gravação conforme definido pela definição de Propriedade e 1335

pelo schema associado para a Interface leitura-gravação. 1336

1337

As seguintes Propriedades Comuns para todos os Recursos são especificadas na seção 1338

7.3.2.2 através da seção 7.3.2.6 e sumarizadas da seguinte forma: 1339

1340

• Tipo de Recurso (“rt”) - esta Propriedade é usada para declarar o Tipo de Recurso de tal 1341

Recurso. Uma vez que é possível que um Recurso seja definido por mais do que um Tipo de 1342

Recurso, é possível usar o Valor de Propriedade da Propriedade do Tipo de Recurso para 1343


declarar mais de um tipo de Recurso. Por exemplo: “rt”: [“oic.wk.d”, “oic.d.airconditioner”] 1344

declara que o Recurso que contém essa Propriedade é definido pelo Tipo de Recurso 1345

“oic.wk.d” ou o Tipo de Recurso “oic.d.airconditioner”. Vide detalhes na seção 7.3.2.3. 1346

• Interface (“if”) - esta Propriedade declara as Interfaces suportadas pelo Recurso. É possível 1347

que o Valor de Propriedade da Propriedade de Interface seja de múltiplos valores e liste todas 1348

as Interfaces suportadas. Vide detalhes na seção 7.3.2.4. 1349

• Nome (“n”) - a Propriedade declara o nome “amigável para humanos” atribuído ao Recurso. 1350

Vide seção 7.3.2.5. 1351

• Identidade de Recurso (“id”): seu Valor de Propriedade precisa ser um identificador de 1352

instância único (ao longo do escopo do Servidor host) para uma instância específica do 1353

Recurso. A codificação desse identificador depende de dispositivo e de implementação. Vide 1354

detalhes na seção 7.3.2.6. 1355

1356

7.3.2.2 Definições de Nome de Propriedade e Valor d e Propriedade 1357

O Nome de Propriedade e o Valor de Propriedade, conforme usados nesta especificação: 1358

• Nome de Propriedade - a chave no par “chave=valor”. O Nome de Propriedade diferencia 1359

entre letras maiúsculas e minúsculas e seu tipo de dados é “cadeia”, mas apenas caracteres 1360

ASCII são permitidos, e caracteres nulos incorporados não são permitidos. 1361

• Valor de Propriedade - o valor no par “chave=valor”. O Valor de Propriedade diferencia entre 1362

letras maiúsculas e minúsculas quando seu tipo de dados é “cadeia”. Quaisquer valores enum 1363

precisam ser apenas ASCII. 1364

1365

7.3.2.3 Tipo de Recurso 1366

A Propriedade de Tipo de Recurso é especificada na seção 7.4. 1367

1368

7.3.2.4 Interface 1369

A Propriedade de Interface é especificada na Seção 7.5. 1370

1371

7.3.2.5 Nome 1372

Um nome amigável para humanos para o Recurso, ou seja, um nome de instância de recurso 1373

específico (por exemplo, MyLivingRoomLight), A Propriedade de Nome é conforme definido na 1374

Tabela 2 1375

Tabela 2. Definição de Propriedade de Nome 1376

Título da propriedade

Nome da propriedade

Tipo do valor

Regra de valor

Unidade

Modo de

acesso Obrigatório Descrição

1377

A Propriedade ‘Nome’ é leitura-gravação, a menos que restrito de outra forma pelo Tipo de 1378

Recurso (ou seja, o Tipo de Recurso não suporta ATUALIZAR ou não suporta ATUALIZAR que 1379

usa leitura-gravação). 1380


1381

7.3.2.6 Identidade de Recurso 1382

A Propriedade de Identidade de Recurso precisa ser um identificador de instância única (ao 1383

longo do escopo do Servidor host) para uma instância do Recurso específica. A codificação 1384

desse identificador depende de dispositivo e de implementação. A Propriedade de Identidade 1385

de Recurso é conforme definido na Tabela 3. 1386

Tabela 3. Definição de Propriedade de Identidade de Recurso 1387

Título de propriedade

Nome de proprieda

de

Tipo de valor

Regra de valor

Unidade

Modo de


1388

7.4 Tipo de Recurso 1389


Tipo de Recurso é uma classe ou categoria de Recursos e um Recurso é uma instância de um 1391

ou mais Tipos de Recurso. 1392

1393

Os Tipos de Recurso de um Recurso são declarados através do uso da Propriedade Comum 1394

de Tipo de Recurso, conforme descrito na Seção 7.3.2.3 ou em um Link que usa o Parâmetro 1395

de Tipo de Recurso. 1396

1397

Um Tipo de Recurso pode ser predefinido (Tipos de Recurso Central nesta especificação e 1398

Tipos de Recurso Verticais em especificações de domínio vertical) ou em definições 1399

customizadas por fabricantes, usuários finais, ou desenvolvedores de Dispositivos (Tipos de 1400

Recurso definidos pelo vendedor). Tipos de Recurso e seus detalhes de definição podem ser 1401

comunicados fora de faixa (ou seja, em documentação) ou ser definidos explicitamente através 1402

do uso de uma metalinguagem que pode ser baixada e usada por APIs ou aplicações. O OCF 1403

adotou RAML e schema JSON como o método de especificação para interfaces RESTful de 1404

OCF e definições de Recurso. 1405

1406

Todo Tipo de Recurso precisa ser identificado com um ID de Tipo de Recurso que precisa ser 1407

representado através do uso das exigências e do ABNF que rege o atributo de Tipo de Recurso 1408

na RFC 6690 da IETF (Seção 2 para ABNF e Seção 3.1 para exigências) com a ressalva de 1409

que segmentos são separados por um “.” (ponto final). A cadeia inteira representa o ID de Tipo 1410

de Recurso. Ao definir o ID, cada segmento pode representar qualquer semântica que seja 1411

apropriada ao Tipo de Recurso. Por exemplo, cada segmento pode representar um 1412

namespace. Assim que o ID houver sido definido, o ID deve ser usado de forma opaca e uma 1413

implementação não deve inferir nenhuma informação dos segmentos individuais. A cadeia 1414

“oic”, quando usada como o primeiro segmento na definição do ID de Tipo de Recurso, é 1415

reservada para Tipos de Recurso definidos por OFC. Todos os Tipos de Recurso definidos por 1416

OCF têm que ser registrados no registro de Parâmetros Centrais IANA conforme descrito 1417


também na RFC 6690 da IETF. 1418

1419

Propriedade de Tipo de Recurso 1420

Um Recurso, quando instanciado ou criado precisa ter um ou mais Tipos de Recurso que 1421

sejam o modelo para tal Recurso. Os Tipos de Recurso aos quais o Recurso se conforma 1422

precisa ser declarado através do uso da Propriedade Comum “rt” para o Recurso. O Valor de 1423

Propriedade para a Propriedade Comum “rt” precisa ser a lista de IDs de Tipo de Recurso para 1424

os Tipos de Recurso usados como modelos (ou seja, “rt”=). 1425

Tabela 4. Definição de Propriedade Comum de Tipo de Recurso 1426


Nome de proprieda

de

Tipo de valor

Regra de valor

Unidade

Modo de

acesso

Obrigatório

Descrição

1427

Tipos de Recurso podem ser descobertos explicitamente ou compartilhados implicitamente 1428

entre o usuário (ou seja, o Cliente) e o host (ou seja, o Servidor) do Recurso. 1429

1430

7.4.3 Definição de Tipo de Recurso 1431

O Tipo de Recurso é especificado da seguinte forma 1432

1433

• URI Predefinido (opcional) - um URI predefinido pode ser especificado para um Tipo de 1434

Recurso específico em uma especificação OCF. Quando um Tipo de Recurso tem um URI 1435

predefinido, todas as instâncias de tal Tipo de Recurso precisam usar apenas o URI 1436

predefinido. Uma instância de um Tipo de Recurso diferente não pode usar o URI predefinido. 1437

• Título de Tipo de Recurso (opcional) - um nome amigável para humanos para designar o 1438

Tipo de Recurso. 1439

• ID de Tipo de Recurso - o valor da propriedade “rt” que identifica o Tipo de Recurso (por 1440

exemplo, “oic.wk.p”). 1441

• Interfaces de Recurso - lista das interfaces quem podem ser suportadas pelo Tipo de 1442

Recurso.1443


• Propriedades de Recurso - definição de todas as propriedades que se aplicam ao Tipo de 1444

Recurso. A definição do Tipo de Recurso precisa definir se uma propriedade é obrigatória, 1445

obrigatória condicional ou opcional. 1446

• Tipos de Recurso Relacionados (opcional) - a especificação de outros Tipos de Recurso 1447

que podem ser referenciados como parte do Tipo de Recurso, aplicável a coleções. 1448

• Tipo Mime (opcional) - tipos mime suportados pelo recurso, incluindo serializações (por 1449

exemplo, application/cbor, application/json, application/xml). 1450

A Tabela 5 e a Tabela 6 fornecem uma descrição exemplificativa de um Tipo de Recurso 1451

foobar ilustrativo e suas Propriedades associadas. 1452

Tabela 5. Tipo de Recurso foobar exemplificativo 1453

URI predefinido

Título do Tipo de Recurso

ID de Tipo de Recurso (valor

“rt”) interfaces Descrição

Interação Funcional

Relacionada M/CR/O

1454

Tabela 6. Propriedades foobar exemplificativas 1455


Nome da proprieda

de

Tipo de valor

Regra de

valor

Unidade

Modo de acesso

Obrigatório Descrição

1456

Uma instância do Tipo de Recurso foobar é conforme mostrado abaixo 1457

1458

Um schema exemplificativo para o Tipo de Recurso foobar é mostrado abaixo 1459

1460

7.4.4 Recurso “rt” Multivalor 1461

Recurso “rt” multivalor significa um Recurso com múltiplos Tipos de Recurso. Tal Recurso é 1462

associado a múltiplos Tipos de Recurso e, portanto, tem um Valor de Propriedade “rt” de 1463


múltiplo IDs de Tipo de Recurso (por exemplo, “rt”: [“oic.r.switch.binary”, 1464

“oic.r.light.brightness”]). A ordem dos IDs de Tipo de Recurso no Valor de Propriedade “rt” é 1465

insignificante. Por exemplo, “rt”: [“oic.r.switch.binary”, “oic.r.light.brightness”] e “rt”: 1466

[“oic.r.light.brightness”, “oic.r.switch.binary”] têm o mesmo significado. 1467

Tipos de Recurso para Recursos “rt” multivalor precisam atender as seguintes condições. 1468

1469

• Nome de Propriedade - Os Nomes de Propriedade para cada Tipo de Recurso precisam ser 1470

únicos (dentro do escopo do Recurso “rt” multivalor) com a exceção de Propriedades Comuns, 1471

caso contrário, haverá semântica de Propriedade conflitante. Se dois Tipos de Recurso têm 1472

uma Propriedade com o mesmo Nome de Propriedade, um Recurso “rt” multivalor não pode ser 1473

composto desses Tipos de Recurso. 1474

1475

Um Recurso “rt” multivalor atende a todas as exigências para cada Tipo de Recurso e se 1476

adequa às definições RAML/JSON para cada Tipo de Recurso componente. Assim, as 1477

Propriedades obrigatórias de um Recurso “rt” multivalor precisam ser a união de todas as 1478

Propriedades obrigatórias de cada Tipo de Recurso. Por exemplo, as Propriedades obrigatórias 1479

de um Recurso com “rt”: [“oic.r.switch.binary”, “oic.r.light.brightness”] são “valor” e “brightness”, 1480

sendo que o primeiro é obrigatório para “oic.r.switch.binary” e o último para 1481

“oic.r.light.brightness”. 1482

1483

O conjunto de Interface de Recurso “rt” precisa ser a união dos conjuntos de interfaces dos 1484

Tipos de Recurso componentes. A Representação de Recurso em resposta a uma ação 1485

CRUDN em uma Interface precisa ser a união dos schemas que são definidos para tal 1486

Interface. A Interface Padrão para um Recurso “rt” multivalor precisa ser a Interface de linha de 1487

base (“oic.if.baseline”), uma vez que essa é a única Interface comum garantida entre os Tipos 1488

de Recurso. 1489

1490

Para esclarecer se cada Tipo de Recurso suporta o mesmo conjunto de Interfaces, então o 1491

Recurso “rt” multivalor resultante tem esse mesmo conjunto de Interfaces com uma Interface 1492

Padrão de linha de base (“oic.if.baselilne”). 1493

1494

Um consulta “rt” para um Recurso “rt” multivalor com a Interface Padrão de “oic.if.a”, “oic.if.s”, 1495

“oic.if.r”, “oic.if.rw” ou “oic.if.baseline” é uma extensão de uma consulta “rt” genérica. Quando 1496

um Servidor recebe uma solicitação RECUPERAR para Recurso “rt” multivalor com um 1497

consulta “rt”, (ou seja, OBTER /ResExample?rt=oic.r.foo), o Servidor deve responder apenas 1498

quando o valor da consulta é um item do Valor de Propriedade “rt” do Recurso alvo e deve 1499

enviar de volta apenas as Propriedades associadas ao valor da consulta. Por exemplo, após 1500

receber OBTER /ResExample?rt=oic.r.switch.binary visando um Recurso com “rt”: 1501

[“oic.r.switch.binary”, “oic.r.light.brightness”], o Servidor responde apenas com as Propriedades 1502

de oic.r.switch.binary. 1503


1504

7.5 Tipo de Dispositivo 1505

Um Tipo de Dispositivo é uma classe de Dispositivo. Cada Tipo de Dispositivo definido incluirá 1506

uma lista de Tipos de Recurso mínimos que um dispositivo precisa implementar para tal Tipo 1507

de Dispositivo. Um dispositivo pode expor Tipos de Recurso definidos padrão e de vendedor 1508

adicional além da lista mínima. O Tipo de Dispositivo é usado em descoberta de Recurso 1509

conforme especificado na seção 11.3.4. 1510

1511

Como um Tipo de Recurso, é possível usar um Tipo de Dispositivo na Propriedade Comum de 1512

Tipo de Recurso ou em um Link que usa o Parâmetro de Tipo de Recurso. 1513

1514

Um Tipo de Dispositivo pode ser predefinido (em especificações de domínio vertical) ou em 1515

definições personalizadas por fabricantes, usuários finais ou desenvolvedores de Dispositivos 1516

(Tipos de Dispositivo definidos por vendedor). Os Tipos de Dispositivo e seus detalhes de 1517

definição podem ser comunicados fora de faixa (como em documentação). 1518

1519

Todo Tipo de Dispositivo precisa ser identificado com um ID de Tipo de Recurso que use as 1520

mesmas restrições de sintaxe que um Tipo de Recurso. 1521

1522

7.6 Interface 1523


Uma Interface fornece primeiro uma vista do Recurso e então define as solicitações e 1525

respostas permissíveis em tal vista do Recurso. Assim, essa vista fornecida por uma Interface 1526

define o contexto para solicitações e respostas em um Recurso. Portanto, a mesma solicitação 1527

para um Recurso, quando direcionado para diferentes Interfaces, pode resultar em diferentes 1528

respostas. 1529

1530

Uma Interface pode ser definida por esta especificação (uma Interface Central), pelas 1531

especificações OCF de domínio vertical (uma “Interface vertical) ou por fabricantes, usuários 1532

finais ou desenvolvedores de Dispositivos (uma “Interface definida por vendedor”). 1533

1534

A Propriedade de Interface lista todas as Interfaces o que Recurso suporta. Todos os recursos 1535

precisam ter pelo menos uma Interface. A Interface Padrão precisa ser definida por uma 1536

especificação OCF e herdada da definição do Tipo de Recurso. A Interface Padrão associada a 1537

todos os Tipos de Recurso definidos nesta especificação precisa ser a Interface suportada 1538

listada primeiro dentro da enumeração aplicável na definição do Tipo de Recurso (vide Anexo 1539

D). Todas as Interfaces Padrão especificadas em uma especificação OCF precisam ser 1540

obrigatórias. 1541

1542

Além de qualquer interface definida de especificação OCF, todos os Recursos precisam 1543


suportar a Interface de Linha de Base (“oic.if.baseline”), conforme definido na seção 7.6.3.2. 1544

1545

Quando uma Interface é selecionada para uma Solicitação, ela precisa ser especificada como 1546

parâmetro de consulta no URI do Recurso na mensagem de Solicitação. Se nenhum parâmetro 1547

de consulta for especificado, então a Interface Padrão precisa ser usada. Se a Interface 1548

selecionada não é uma das Interfaces permitidas no Recurso, então selecionar essa Interface é 1549

um erro. 1550

1551

Uma Interface pode aceitar mais de um Tipo de mídia. Uma Interface pode responder com 1552

mais de um tipo de mídia. Os tipos de mídia aceitos podem ser diferentes dos tipos de mídia de 1553

resposta. Os tipos de mídia são especificados com os parâmetros de cabeçalho apropriados no 1554

protocolo de transferência. (OBSERVAÇÃO: Essa característica tem que ser usada 1555

criteriosamente e pode otimizar representações em fio) Cada Interface precisa ter pelo menos 1556

um Tipo de mídia. 1557

1558

7.6.2 Propriedade de Interface 1559

Tabela 7. Definição de Interface de Propriedade de Recurso 1560


Nome da proprieda

de

Tipo de valor

Regra de valor

Unidade

Modo de


1561

As Interfaces suportadas por um Recurso precisam ser declaradas através do uso da 1562

Propriedade Comum de Interface (Tabela 7) como “if=“. O Valor de 1563

Propriedade de uma Propriedade de Interface precisa ser um cadeia em letras minúsculas com 1564

segmentos separados por um “.” (ponto final). A cadeia “oic”, quando usada como o primeiro 1565

segmento no Valor de Propriedade de Interface, é reservada para Interfaces definidas por 1566

OCF. O Valor de Propriedade de Interface pode também ser uma referência a uma autoridade 1567

similar à IANA que pode ser usado para encontrar a definição de uma Interface. Um Tipo de 1568

Recurso precisa suportar uma ou mais das Interfaces definidas na seção 7.6.3. 1569

1570

7.6.3 Métodos de interface 1571

7.6.3.1 Visão Geral 1572

As Interfaces definidas por OCF são listadas na tabela abaixo: 1573

Tabela 8. Interfaces padrão OCF 1574

Interface Nome Métodos Aplicáveis

Descrição


1575

7.6.3.2 Interface de Linha de Base 1576

7.6.3.2.1 Visão Geral 1577

A Representação que é visível usando a Interface “linha de base” inclui todas as Propriedades 1578

do Recurso que incluem as Propriedades Comuns. A Interface “linha de base” precisa ser 1579

definida para todos os Tipos de Recurso. Todos os Recursos precisam suportar a Interface 1580

“linha de base”. 1581

1582

A Interface “linha de base” é selecionada adicionando-se “if=oic.if.baseline” à lista de 1583

parâmetros de consulta no URI do Recurso alvo. Por exemplo: “OBTER 1584

/oic/res?if=oic.if.baseline”. 1585

1586

7.6.3.2.2 Uso de RECUPERAR 1587

A Interface “linha de base” é usada quando um Cliente deseja recuperar todas as Propriedades 1588

de um Recurso. O Cliente inclui a definição do parâmetro de consulta de URI 1589

“?if=oic.if.baseline” em uma solicitação RECUPERAR. Quando essa definição de parâmetro de 1590

consulta é incluída, o Servidor precisa responder com uma representação de Recurso que 1591

inclua todas as Propriedades do Recurso implementadas. Quando o Servidor é incapaz de 1592

enviar de volta toda a representação de Recurso, o Servidor precisa responder com uma 1593

mensagem de erro. O Servidor não pode retornar uma representação de Recurso parcial. 1594

1595

Uma resposta exemplificativa a uma solicitação RECUPERAR que usa a Interface de linha de 1596

base é mostrada abaixo: 1597

1598

7.6.3.2.3 Uso de ATUALIZAR 1599

Através do uso da Interface de linha de base, todas as Propriedades de um Recurso, com a 1600

exceção de Propriedades Comuns, podem ser modificadas com o uso de uma solicitação 1601


ATUALIZAR com uma lista de Propriedades e seus valores desejados se um Tipo de Recurso 1602

tiver um schema associado para ATUALIZAR com o uso de linha de base. 1603

1604

7.6.3.3 Interface de Lista de Link 1605

7.6.3.3.1 Visão Geral 1606

A Interface de lista de links fornece uma vista dentro da lista de Links em uma Coleção 1607

(Recurso). A Representação visível através dessa Interface tem apenas os Links definidos no 1608

Valor de Propriedade da Propriedade “links” - assim, essa Interface é usada para manipular ou 1609

interagir com a lista de Links em uma Coleção. A lista de Links pode ser RECUPERAda com o 1610

uso dessa Interface. 1611

1612

A definição e semântica de Interface são dadas da seguinte forma: 1613

• O nome da Interface de lista de links precisa ser “oic.if.ll”. 1614

• Se especificado em uma solicitação (geralmente no cabeçalho da solicitação), a serialização 1615

na resposta precisa ser no formato esperado na solicitação. 1616

• Em resposta a uma solicitação RECUPERAR na Interface “links list”, os URIs dos Recursos 1617

especificados precisam ser retornados como uma referência URI. 1618

• Se não há links presentes em um Recurso, então uma lista vazia precisa ser retornada. 1619

• A Representação determinada por essa vista de Interface apenas inclui o Valor de 1620

Propriedade da Propriedade “links”. Assim, a Coleção ou resposta /oic/res com oic.if.ll é uma 1621

matriz de Links OCF. 1622

7.6.3.3.2 Exemplo: Interface “links list” 1623

Exemplo: Solicitação a uma Coleção 1624

1625


1626

7.6.3.4 Interface de Lote 1627

7.6.3.4.1 Visão Geral 1628

A Interface de lote é usada para interagir com uma coleção de Recursos com o uso de uma 1629

única/mesma Solicitação. A Interface de lote suporta métodos de Recursos nos Links da 1630

Coleção, e é possível usar a Interface de lote para RECUPERAR ou ATUALIZAR as 1631

Propriedades dos Recursos “linked” com uma única representação de Recurso. 1632

1633

A Interface de lote seleciona uma vista dentro dos Links em uma Coleção - a Solicitação é 1634

enviada a todos os Links nessa vista com possíveis modificações definidas nos Parâmetros do 1635

Link 1636

1637

A Interface de lote é definida da seguinte forma 1638

• O nome da Interface de lote precisa ser “oic.if.b” 1639

• Um Recurso de Coleção com uma Interface de lote tem Links que têm referências de Recurso 1640


que podem ser URIs (totalmente qualificados para Recursos remotos) ou referências relativas 1641

(para Recursos locais). 1642

• A solicitação original é modificada para criar novas solicitações que visam cada um dos alvos 1643

nos Links de Recurso substituindo-se o URI na solicitação original pelo URI do Recurso alvo no 1644

Link. A carga na solicitação original é replicada na carga das novas Solicitações. 1645

• As Solicitações precisam ser encaminhadas presumindo o uso da Interface Padrão dos 1646

Recursos especificados. 1647

• As Solicitações apenas precisam ser encaminhadas para alvos de link que sejam 1648

identificados como itens na coleção pelos tipos de relação “item” ou “hosts” (“hosts” é o tipo de 1649

relação padrão). Solicitações não podem ser encaminhadas para alvos de links que não 1650

contêm os valores de tipo de relação “item” ou “hosts”. O tipo de relação “hosts” padrão precisa 1651

ter permissão para links absolutos e relativos. 1652

• Recursos da própria coleção podem ser incluídos no lote através do uso da relação de link 1653

“self” junto com “item” e garantindo que a interface padrão da coleção não exponha a 1654

propriedade dos links, ou seja, não “oic.if.baseline” ou “oic.if.ll”. 1655

• Todas as Respostas dos Recursos de item vinculados precisam ser agregadas na Resposta 1656

única ao Cliente. O Servidor pode exceder o tempo de espera da Resposta a uma janela de 1657

tempo (se uma janela de tempo houver sido negociada com o Cliente, então o Servidor não 1658

pode esgotar o tempo de espera dentro dessa janela; na ausência de janela negociada, o 1659

Servidor pode escolher qualquer janela apropriada com base nas condições). Se os Recursos 1660

alvo não puderem processar a nova solicitação, uma resposta vazia ou resposta de erro 1661

precisa ser retornada. Essas Respostas vazias/de erro precisam ser incluídas na Resposta 1662

agregada à Solicitação do Cliente original. 1663

• A representação de lote é uma matriz de objetos que representa as respostas dos recursos 1664

vinculados. Cada objeto na resposta de lote precisa incluir pelo menos dois itens: (1) o URI do 1665

recurso vinculado (totalmente qualificado para recursos remotos, ou uma referência relativa 1666

para recursos locais) como “href”: e (2) o objeto de resposta individual como “rep” como 1667

a chave, ou seja, “rep”: { < representação da resposta individual> }. 1668

• Recursos especificados por links na coleção podem ser observados com o uso da interface 1669

de lote da coleção. O mecanismo de observação precisa funcionar conforme definido em 1670

11.4.2. Especificamente, as representações e os códigos de status precisam ser os mesmos 1671

que para as operações RECUPERAR que usam a interface de Lote. 1672

• Propriedades do próprio recurso de coleção podem ser observadas através do uso da 1673

interface apropriada. Por exemplo, uma coleção pode ser observada em sua lista vinculada ou 1674

interface de linha de base para receber notificações de mudanças em seus links. 1675

• O Cliente pode escolher restringir a lista de Links aos quais a Solicitação é encaminhada 1676

através da inclusão de parâmetros de consulta no URI da Coleção para a qual essa Solicitação 1677

de Interface de ‘lote’ original é feita. O Servidor deve processar parâmetros de consulta em 1678

uma solicitação que inclua “oic.if.b”, como seletores para links na Coleção que será processada 1679

no lote. 1680


• As operações de Lote ATUALIZAR são realizadas através da criação de uma carga conforme 1681

o mesmo ame schema da carga do Lote RECUPERAR. Um conjunto de solicitações 1682

ATUALIZAR específicas de link é criado conforme os tags “href” nos itens incluídos e a carga 1683

contida no valor da propriedade “rep” é aplicada ao item especificado “href” correspondente. 1684

• Se a propriedade solicitada para ATUALIZAR não existir no recurso vinculado, ela precisa 1685

ignorar silenciosamente a solicitação. 1686

• Se o valor “href” é o URI vazio, denotado por uma cadeia de comprimento zero ou ““ em 1687

JSON, a carga no valor da propriedade “rep” é aplicada a todos os itens de lote na Coleção. 1688

• Itens com os “href” vazio e “href” específico de link não podem ser misturados na mesma 1689

carga ATUALIZAR. 1690

• A Representação na Solicitação específica de Link pode não combinar com a Representação 1691

exposta pela Interface Padrão no Recurso alvo. Em tais casos, a semântica ‘subconjunto’ se 1692

aplica, sendo que as Propriedades na Solicitação que combina com as Propriedades na vista 1693

de Recurso exposta precisam ser modificadas no Recurso alvo se a Propriedade for gravável. 1694

• A resposta a POSTAR precisa conter os valores atualizados através do uso do mesmo 1695

schema de carga que as operações RECUPERAR, junto com o código de status apropriado. A 1696

carga de resposta precisa refletir o estado conhecido das propriedades de recurso atualizadas 1697

após a atualização de lote ter sido concluída. 1698

1699

7.6.3.4.2 Uso de Parâmetros de Consulta com Lote 1700

Parâmetros de consulta adicionais podem ser usados com a interface de lote a fim de 1701

selecionar itens em particular no lote para recuperação ou atualização. Quando parâmetros 1702

adicionais que não sejam interpretados de outras formas são incluídos, esses parâmetros são 1703

usados para selecionar itens no lote através da combinação de valores de atributo de link. 1704

1705

Um item em particular em um lote é selecionado por parâmetros de consulta adicionais em 1706

uma solicitação se, e somente se, todos os parâmetros de consulta de seleção de link 1707

continham valores que combinam com valores correspondentes nos atributos de link desse 1708

item. 1709

1710

Quando os parâmetros de consulta de seleção de link são usados com operações 1711

RECUPERAR, apenas os itens com atributos de link que combinam são retornados. 1712

1713

Quando os parâmetros de consulta de seleção de link são usados com operações ATUALIZAR, 1714

apenas os itens que têm atributos de link que combinam são atualizados. 1715

1716

Vide exemplos de operações RECUPERAR e ATUALIZAR que usam parâmetros de consulta 1717

de seleção de link em 7.6.3.4.3. 1718

1719

7.6.3.4.3 Exemplos: Interface de Lote 1720


Exemplo 1 1721

1722


1723


1724


1725


1726

Exemplo que mostra adicionalmente a interface “links list” e “batch” 1727


1728

1729

7.6.3.5 Interface de Atuador 1730

A Interface de atuador é a Interface para visualizar Recursos que podem ser atuados, ou seja, 1731

muda algum valor dentro da entidade abstraída pelo Recurso ou muda o estado de tal 1732

entidade: 1733

1734

• O nome da Interface de atuador precisa ser “oic.if.a” 1735

• A Interface de atuador precisa expor na Representação de Recurso todas as Propriedades 1736

obrigatórias conforme definidas pelo JSON aplicável; a interface de atuador pode também 1737

expor na Representação de Recurso Propriedades opcionais conforme definidas pelo schema 1738

JSON aplicável que são implementadas pelo Dispositivo alvo. 1739


1740

1741

• Uma solicitação RECUPERAR que usa essa Interface precisa retornar a Representação para 1742

esse Recurso sujeito a quaisquer parâmetros de filtro e consulta que também possam existir 1743

• Uma solicitação ATUALIZAR que usa essa Interface precisa fornecer uma carga ou corpo que 1744

contenha as Propriedades que serão atualizadas no Recurso alvo. 1745

1746


7.6.3.6 Interface de Sensor 1747

A Interface de sensor é a Interface para recuperar informações específicas medidas, 1748

detectadas ou de capacidade de um Recurso que detecte: 1749

• O nome da Interface de sensor precisa ser “oic.if.s” 1750

•A Interface de sensor precisa expor na Representação de Recurso todas as Propriedades 1751

obrigatórias conforme definidas pelo JSON aplicável; a interface de sensor pode também expor 1752

na Representação de Recurso opcional Propriedades conforme definido pelo schema JSON 1753

aplicável que são implementadas pelo Dispositivo alvo. 1754

• Uma solicitação RECUPERAR que usa essa Interface precisa retornar essa Representação 1755

para o Recurso sujeito a quaisquer parâmetros de filtro e consulta que também possam existir 1756

1757

7.6.3.7 Interface de Apenas leitura 1758

A Interface de apenas leitura expõe apenas as Propriedades que pode ser “lidas”. Isso inclui 1759

Propriedades que podem ser “apenas leitura”, “leitura-gravação”, mas não Propriedades que 1760

são “apenas gravação” ou “apenas conjunto”. Os 1761

métodos aplicáveis cuja aplicação a um Recurso é possível são apenas RECUPERAR. Uma 1762

tentativa por um Cliente de aplicar um método que não seja RECUPERAR a um Recurso 1763

precisa ser rejeitada com um código de resposta de erro. 1764

1765


7.6.3.8 Interface leitura-gravação 1766

A Interface leitura-gravação expõe apenas as Propriedades que podem ser “lidas” e 1767

“gravadas”. As Propriedades “apenas leitura” não podem ser incluídas em Representação para 1768

a Interface “leitura-gravação”. Essa é uma Interface genérica para suportar as Propriedades 1769

“leitura” e “configuração” em um Recurso. Os métodos aplicáveis cuja aplicação a um Recurso 1770

é possível são apenas RECUPERAR e ATUALIZAR. Uma tentativa por um Cliente de aplicar 1771

um método que não seja RECUPERAR ou ATUALIZAR a um Recurso precisa ser rejeitada 1772

com um código de resposta de erro. 1773

1774

7.7 Representação de recurso 1775

A representação de recurso captura o estado de um Recurso em um determinado momento. A 1776

representação de recurso é trocada nas interações de solicitação e resposta com um Recurso. 1777

Uma representação de Recurso pode ser usada para recuperar ou atualizar o estado de um 1778

recurso. 1779

1780

A representação de recurso não pode ser manipulada pelos pro

ocf core specifiation - open connectivity foundation (ocf)...direitos autorais open connectivity...

Documents