-
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