ocf core specifiation - open connectivity foundation (ocf)...direitos autorais open connectivity...
TRANSCRIPT
-
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 2
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 3
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 4
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 5
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 6
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 7
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 8
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 9
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 10
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 11
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 12
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 13
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 14
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 15
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 16
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 17
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 18
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 19
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 20
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 21
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 22
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 23
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 24
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 25
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
acesso Obrigatório Descrição
1388
7.4 Tipo de Recurso 1389
7.4.1 Introdução 1390
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 26
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
Título de propriedade
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 27
• 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
Título de propriedade
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 28
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 29
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
7.6.1 Introdução 1524
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 30
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
Título de propriedade
Nome da proprieda
de
Tipo de valor
Regra de valor
Unidade
Modo de
acesso Obrigatório Descrição
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 31
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 32
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 33
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 34
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 35
• 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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 36
Exemplo 1 1721
1722
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 37
1723
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 38
1724
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 39
1725
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 40
1726
Exemplo que mostra adicionalmente a interface “links list” e “batch” 1727
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 41
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 42
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 43
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
-
Direitos Autorais Open Connectivity Foundation, Inc. © 2016-2017. Todos os direitos reservados 44
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